Subject | Table Inheritance |
---|---|
Author | Jim Starkey |
Post date | 2000-07-17T18:42:13Z |
If I remember correct, we had been talking about trigger templates
and table inheritance. The problem at hand as the burden of maintain
a very large number of highly similar triggers on a set of tables.
The example given was a pair of triggers that updated a pair of
field, last_update_date and last_update_user.
The original proposal was to implement a template mechanism
a la C++ to instantiate a trigger template for each table.
The objects raised where that even with templates, a trigger
definition was still required per table, though the trigger
body might be shorter, and that the cost of the implementation
might be greater than the actual benefit.
I proposed an alternative solution in which a base table containing,
among other stuff, the fields last_update_date and last_update_user
and the triggers to maintain those fields. Other tables could then
"extend" the base table, inheriting both the fields and the triggers.
Table inheritance, however, raises all sorts of interesting questions
that beg answers before we can even start arguing about implementation
stategy. Nice, thick, yummy sort of questions.
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.
create table base (last_update_date, last_update_user)
create trigger for base ...
create table products (product_number...) extends base;
create table customers (customer_number...) extends base;
insert into products (product_number) values (123)
insert into customers (customer_number) values (456)
Simple inheritance:
select count (*) from base
0
Semantic model:
select count (*) from base
2
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).
Question 3: Is multiple inheritence necessary? Most language
designers would say that multiple inheritence is mother natures
way of telling you that your design is screwed up. Multiple
inheritence in C++ is moby complicated and usually does the
wrong thing. Java dump it in favor of single inheritance
plus implementation of interfaces (polymorphism without
representation). What is the minimal feature set we can live
with?
Jim Starkey
and table inheritance. The problem at hand as the burden of maintain
a very large number of highly similar triggers on a set of tables.
The example given was a pair of triggers that updated a pair of
field, last_update_date and last_update_user.
The original proposal was to implement a template mechanism
a la C++ to instantiate a trigger template for each table.
The objects raised where that even with templates, a trigger
definition was still required per table, though the trigger
body might be shorter, and that the cost of the implementation
might be greater than the actual benefit.
I proposed an alternative solution in which a base table containing,
among other stuff, the fields last_update_date and last_update_user
and the triggers to maintain those fields. Other tables could then
"extend" the base table, inheriting both the fields and the triggers.
Table inheritance, however, raises all sorts of interesting questions
that beg answers before we can even start arguing about implementation
stategy. Nice, thick, yummy sort of questions.
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.
create table base (last_update_date, last_update_user)
create trigger for base ...
create table products (product_number...) extends base;
create table customers (customer_number...) extends base;
insert into products (product_number) values (123)
insert into customers (customer_number) values (456)
Simple inheritance:
select count (*) from base
0
Semantic model:
select count (*) from base
2
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).
Question 3: Is multiple inheritence necessary? Most language
designers would say that multiple inheritence is mother natures
way of telling you that your design is screwed up. Multiple
inheritence in C++ is moby complicated and usually does the
wrong thing. Java dump it in favor of single inheritance
plus implementation of interfaces (polymorphism without
representation). What is the minimal feature set we can live
with?
Jim Starkey