Re: [HACKERS] Re: ORDBMS

Поиск
Список
Период
Сортировка
Искать
От
Chris Bitmead
Тема
Re: [HACKERS] Re: ORDBMS
Дата
Msg-id
3894D813.3C2EE1BF@bitmead.com
Список
Дерево обсуждения
Well, then you keep your darn columns Peter Eisentraut <e99re41@DoCS.UU.SE>
Re: [HACKERS] Well, then you keep your darn columns Bruce Momjian <pgman@candle.pha.pa.us>
Re: [HACKERS] Well, then you keep your darn columns Don Baccus <dhogaza@pacifier.com>
RE: [HACKERS] Well, then you keep your darn columns "Hiroshi Inoue" <Inoue@tpf.co.jp>
Re: [HACKERS] Well, then you keep your darn columns Bruce Momjian <pgman@candle.pha.pa.us>
Re: [HACKERS] Well, then you keep your darn columns Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] Well, then you keep your darn columns Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] Well, then you keep your darn columns Don Baccus <dhogaza@pacifier.com>
Re: [HACKERS] Well, then you keep your darn columns The Hermit Hacker <scrappy@hub.org>
Re: [HACKERS] Well, then you keep your darn columns The Hermit Hacker <scrappy@hub.org>
Re: [HACKERS] Well, then you keep your darn columns Bruce Momjian <pgman@candle.pha.pa.us>
Re: [HACKERS] Well, then you keep your darn columns The Hermit Hacker <scrappy@hub.org>
RE: [HACKERS] Well, then you keep your darn columns "Hiroshi Inoue" <Inoue@tpf.co.jp>
Re: [HACKERS] Well, then you keep your darn columns Don Baccus <dhogaza@pacifier.com>
Re: [HACKERS] Well, then you keep your darn columns The Hermit Hacker <scrappy@hub.org>
Re: [HACKERS] Well, then you keep your darn columns Don Baccus <dhogaza@pacifier.com>
Re: [HACKERS] Well, then you keep your darn columns Peter Eisentraut <e99re41@DoCS.UU.SE>
Re: [HACKERS] Well, then you keep your darn columns Philip Warner <pjw@rhyme.com.au>
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
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
В списке pgsql-hackers по дате отправления
От: Chris Bitmead
Дата:
Сообщение: Re: [HACKERS] Re: ORDBMS
От: Chris Bitmead
Дата:
Сообщение: Re: [HACKERS] Re: ORDBMS
FAQ