The Hermit Hacker wrote:
> Not quite an answer to your question, but my guess is that 'address
> ADDRESS' would contain a pointer (OID) to the address table ... so the
> person table would be realtively small in comparison to the address table
I'm 99% sure that this is not the case. Rather the address is embedded
inside
the person object. I think this is basicly what Oracle has done with 8i
too.
I think then if you do SELECT * from person it flattens out all the
fields.
(This might even still work).
Not that the idea of relating to oid as another feature is bad. My last
message I gave the example of how postquel could do this. I think
that design had the advantage that you could construct 1:M relationships
this way too.
Just a trade off a bit like in C++
class Person {Address address;
}
vs
class Person {Address *address;
}
vs
class Person {List<Address> addresses;
}
pros and cons for each one.
> The way I look at the above, its a 'JOIN' at table create time, based on a
> unique value, the OID ...
>
> How 'dep' can you go with this? ie:
>
> CREATE TABLE address (street TEXT, number TEXT, suburb TEXT, zip TEXT);
> CREATE TABLE telephone ( home TEXT, business TEXT, fax TEXT );
> CREATE TABLE person (name TEXT, address ADDRESS, telephone TELEPHONE);
>
> Question, if I did an INSERT person VALUES ('myname');
>
> What happens to the address table? a row gets created with all NULL? Or?
>
> The reason I ask is the way it was taught to me was that an RDBMS gains
> its benefit through normalization and joins ...with the outer join syntax
> coming up, if you had a table of 'person' fully populated, but only
> address info for 1/2 of them, you could still get all 'people', while your
> 'address' table has 1/2 the tuples of the person one ... space savings ...
>
> HSorry, rambling thoughts out o fmy head without putting them together
> very well :)
>
> Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
> Systems Administrator @ hub.org
> primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
