Re: Table design issue....

Поиск
Список
Период
Сортировка
От Alex Pilosov
Тема Re: Table design issue....
Дата
Msg-id Pine.BSO.4.10.10106111323560.16686-100000@spider.pilosoft.com
обсуждение исходный текст
Ответ на Table design issue....  (pierre@kahuna.versions.com)
Ответы Re: Table design issue....  (pierre@kahuna.versions.com)
Список pgsql-sql
Yes, this seems like a bad design. If you feel you need to join
potentially unlimited number of tables, that means all of those tables
really belong in one table. If you can explain why do you think you need
separate tables...?



On 11 Jun 2001 pierre@kahuna.versions.com wrote:

> Hi all,
> 
>   I've got a situation where I need to be able to query for the
> same sort of data across multiple tables. Let me give some example
> tables then explain.
> 
> create table t1 (
>   t_attr1 text[],
>   t_attr2 text[]
> );
> create table a1 (
>   a_attr1 text[],
>   a_attr2 text[]
> );
> create table c1 (
>   c_attr1 text[],
>   c_attr2 text[],
>   c_attr3 text[]
> );
> 
> In each of the above tables *_attr*[1] contains a flag that determines
> what type of attribute it is. 
> t1.t_attr1[1] == a1.a_attr2[1] == c1_.c_attr3[1] == FLAG
> In otherwords, the attribute with the specific flag in quesiton is not 
> known at runtime, unless I keep a table with the column names and table
> names setup. Also, new *1 tables could be created dynamically with new attr*'s, 
> and the number of columns within the tables isn't going to be the same.
> 
> What I need to be able to do is say something like:
> "For ALL *1 tables with *_attr*[1] == FLAG return rows with
> VALUE"
> 
> Ideas? Comments? Suggestions? Am I being crazy?
> 
> Pierre
> 
> 



В списке pgsql-sql по дате отправления:

Предыдущее
От: Luis Sousa
Дата:
Сообщение: Re: Hidden Select
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: Hidden Select