From: | Ivan Cornell <ivan(dot)cornell(at)framestore(dot)co(dot)uk> |
---|---|
To: | Bob Zatolokin <littleB(at)ogl(dot)spb(dot)ru> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: The best table's scheme? |
Date: | 2000-09-27 08:40:04 |
Message-ID: | 39D1B264.ABDFBED5@framestore.co.uk |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Bob Zatolokin wrote:
> I have a such task:
>
> 1. table USERS
> 2. table DEPARTMENTS
> - where each DEPARTMENT needs to store LIST of USERS in it
> 3. table FIRMS
> - where each FIRM needs to store LIST of USERS in it
> 4. table EVENTS
> - and where each EVENT needs to store LIST of _MEMBERS_ - USERS or
> DEPARTMENTS or FIRMS in it
>
It depends whether you have a many-to-one or many-to-many relationship. In the
first case each user is only ever a member of one department, in which case you
can store the dept id in the user table. If each user can be a member of
several firms (moonlighting!), then you do need a separate table to store the
many-to-many relation. This is very efficent if you define indexes on all the
joining fields. I don't recommend going near arrays - I regretted it later &
haven't touched them for years. So a solution might look like:
create table firm_user (
firm_id int4,
user_id int4);
select * from user, firm, firm_user where user.id = firm_user.user_id and
firm.id = firm_user.firm_id
If I don't make sense, look for some documentation on database design,
normalisation & normal-forms,
Ivan
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2000-09-27 09:58:00 | test |
Previous Message | Alexi Margo | 2000-09-27 08:37:07 | RE: Re: Encrypting fields with a one-way hash |