Re: [HACKERS] Re: ORDBMS

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