>> >> The Hermit Hacker <scrappy@hub.org> writes:
>> >> What I don't understand yet is whether the contents of table
>> >> "address" have any connection to the data stored in table "person".
>> >> If not, why must I create a table in order to define a datatype?
>> Seems
>> >> like a separate CREATE DATATYPE command would make more sense...
>> > 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
>> > ...
>> > The way I look at the above, its a 'JOIN' at table create time, based
>> on a
>> > unique value, the OID ...
>>
>> Hmm. OK, that makes sense, because I know I've seen places in the code
>> that think that any "set type" is represented as an OID. I never
>> understood what that was all about, but in this context that would be
>> what would happen. Assuming that this facility is the same as what
>> the code calls a set, that is.
>> So, if I looked into table address, presumably I'd find rows
>> corresponding to each value that is (ever has been?) stored in another
>> table with an ADDRESS column. How do no-longer-useful values get
>> cleaned out of the address table, do you suppose?
There's something that doesn't gel though. From the syntax of the creation,
it looks like the relationship between person and address is one-to-one.
Yet, when storing in separate tables, you are implying a one-to-many
relationship. If it really was one-to-one, you would have the address
fields on the person table. Right?
MikeA