On 15 Oct 2002 at 9:38, Josh Berkus wrote:
> Jules,
>
> > My idea for the new db was someting like this:
> >
> > company(name varchar(100))
> > employee(code int)
> > consultant(name varchar(50))
> > address(ref_oid OID, street varchar(100), state varchar(100))
> >
> > In this way, I can store all the addresses together and find them
> > with.
> > SELECT * WHERE addres.ref_oid = company.oid;
>
> That's a fine idea, except that you have the referential integrity
> backward:
>
> Company(name varchar(100), address_id INT)
> employee(code int, address_id INT)
> consultant(name varchar(50), address_id INT)
> address(address_id INT PRIMARY KEY, street varchar(100), state
> varchar(100))
>
> While there are reasons to do the kind of multi-table join that you
> propose, the standard relational model (above) works better.
<snip>
I just thought of something... If I wanted the possibility to have more
than one address per employee / company / consultant the OID approach
would be better.
A way (other than using OIDs) to solve this "(several tables):N" issue
(if you know what I mean) might be using an array for the address
references:
company(name varchar(50), address_id INT[])
but somehow I don't like the idea of an array datatype -a table within
a table- in the relational model.
