Subject | RE: [IB-Architect] Table Inheritance |
---|---|
Author | Jim Starkey |
Post date | 2000-07-17T20:46:32Z |
At 03:24 PM 7/17/00 -0400, Mark Shapiro wrote:
little in common other than the DDL parse. The attribute inheritance
model would be a 100% system table play -- propogate stuff from the
base table(s) into the target tables. The semantic model could be
implemented with a single physical table containing the union of all
fields plus a "instance type" field. So even if we were completely
sure we wanted both, the implementation would be decoupled. So,
for the purpose of discussion, pick one and explain why.
a single primary index that implements primary keys for all tables
in a type hierarchy is flat impossible. About the only way out that
I can think of is an artificial unique field in the root table. Any
other ideas?
new primary key could automatically drop the old one.
Jim Starkey
>Yes, both could be implemented, but the implementations would have
>>Question 1: Does table inheritance simply mean attribute (fields,
>>triggers, primary keys, indexes) inheritance, or does it mean a
>>a unified semantic model? We could, of course, have both, but
>>for the sake of elegance, lets assume one or the other.
>
>I would say attribute inheritance be a higher priority than a unified
>semantic model. If both are implemented, the create table syntax should
>allow for explicit syntax for selecting either model, in addition to the
>"extends" or similar syntax. The default option should be attribute
>inheritance.
>
little in common other than the DDL parse. The attribute inheritance
model would be a 100% system table play -- propogate stuff from the
base table(s) into the target tables. The semantic model could be
implemented with a single physical table containing the union of all
fields plus a "instance type" field. So even if we were completely
sure we wanted both, the implementation would be decoupled. So,
for the purpose of discussion, pick one and explain why.
>Natural primary keys are a real problem in the unified semantic model --
>>Question 2: Are primary key inherited? Choices: a) yes, b) no,
>>c) declared primary key of extension table appended to primary
>>key of base table (problem is that uniqueness of base table is
>>problematic).
>
>Primary keys are inherited, but may be overridden by either replacing the
>key, removing the key, or appending to the key (possibly with the base key
>being optionally before or after the key in the new table).
>
a single primary index that implements primary keys for all tables
in a type hierarchy is flat impossible. About the only way out that
I can think of is an artificial unique field in the root table. Any
other ideas?
>Removing the key could possibly be done in the Create Table syntax, or byI think you're right about the inherited attribute case. Defining a
>dropping the key after the table is created. This would of course not work
>if the table were created with the unified semantic model, but would work if
>attributes were inherited.
>
new primary key could automatically drop the old one.
Jim Starkey