Re: Thus spoke SQL3 (on OO)
От | Robert B. Easter |
---|---|
Тема | Re: Thus spoke SQL3 (on OO) |
Дата | |
Msg-id | 00052202145407.14806@comptechnews обсуждение исходный текст |
Ответ на | Thus spoke SQL3 (on OO) (Peter Eisentraut <peter_e@gmx.net>) |
Список | pgsql-hackers |
On Sun, 21 May 2000, Chris Bitmead wrote: > Hannu Krosing wrote: > > > Chris, what is your position on having a single primary key for all > > inherited columns ? > > What is the significance of a primary key compared to any old unique > key? For referential integrity, the REFERENCES or FOREIGN KEY clauses specify a table name. That table is expected to have one and only one PRIMARY KEY. You can't select which unque column you want to reference within a table - it must be the one and only PRIMARY KEY. I hope this is answering the question. :) Multiple inheritance and referential integrity are a complex mix. It becomes hard for the database to maintain data integrity and uphold the relational model that is based on functional dependency where one set of atomic values are determined by a key or composite key containing attributes that are not functionally dependent on each other. With multiple inheritance, it is easy to end up with two separate keys determining the same data, which is a conflict if they are not a composite key. Something like that. The EXTENDS type of inheritance is single-inheritance compatible. This is what I think SQL3 is allowing. It allows you to make a hierarchy tree out of tables. Only one primary key can possibly be inherited. A subtable is forbidden from specifying its own primary key - it must inherit one. The CLONES and ASSIMILATES stuff that I mentioned before, would require some restrictions to ensure they don't break the relational model data intergrity enforcement infrastructure (primary keys/foreign keys etc). For example, to multiple inherit, it would maybe be required that the inherited table have an inherited primary key consisting of the composite of all inherited keys. If it inherits no primary key, then it is free to specify one for itself. But remember, that CLONE just branches off from its parents, who are not connected to child so that eases things a litte for that case. ASSIMILATES is more complicated, and is not possible to compare it even with anything you can do in a programming language since a child can exist after a parent class has been dropped. I'd have to think about CLONES and ASSIMILATES more since they multiple inherit. I looks like SQL3 has taken care of the EXTENDS type for us. Attached is a diagram of the way UNDER appears to work in SQL3. The second gif is a rough idea of how I think INHERITS/CLONES might work. The 3rd pic is about the assimilate inheritance idea, which is half baked but maybe somwhat interesting. -- Robert B. Easter reaster@comptechnews.com
В списке pgsql-hackers по дате отправления: