Re: Inheritance

On Thu, 2002-09-05 at 08:15, Hannu Krosing wrote:
> On Thu, 2002-09-05 at 11:34, Curt Sampson wrote:
> > On 5 Sep 2002, Hannu Krosing wrote:

> > If that
> > trigger is acting as an integrety constraint on the base table,
> > you might destroy the table's integrity.
>
> What I try to say is that you should have the same freedom with triggers
> that you have with select/insert/update/delete - you must be able to
> choose if the trigger is on the parent table ONLY or on parent and all
> children.

Sounds like a mechanism to make the distinction between virtual (child
can override parent) and non-virtual (child is constrained by the
parent) constraints are needed.

After all, there are two basic needs for constraints. One is for
relational integrity and the other is business rule integrity. That is,
one seeks to ensure that the database makes sense in respect to the data
model (a shoe is a product) while the other is to enforce business rules
(products are never free). Seems like the DBA should be able to dictate
which domain his constraint falls into in some manner.

>
> And you should be able to override a trigger for child table even if it
> is defined on parent as applying to all children - I guess that
> overriding by trigger _name_ would be what most people expect.
>

That's the reason I used virtual and non-virtual above. If we think
using C++ idioms, the child is stuck with it if it's deemed
non-virtual. Generally speaking, if someone designed something with
that expectation in mind, there's probably a good reason for it. In
this case, we could assume that such non-virtual constraints would be to
help ensure proper RI. Something that otherwise, IMO, would be tossed
out with the bath water.

> What I'm after here is dynamic (and automatic) row level dispach of the
> right function based on row type - so that for rows in CITIZEN or
> CIVIL_SERVANT the function kills_not_others(CITIZEN) will be used but
> for rows in MILITAY the kills_not_others(MILITARY) is used.

I think we're touching on some form of RTTI information here. That is,
triggers and even functions may need to be able to dynamically determine
the row type that is actively being worked on.

If we're on the same page, I think that seemingly makes a lot of sense.

What about the concept of columns being public or private? That is,
certain columns may not be inherited by a child? Any thought to such a
concept? Perhaps different types of table inheritance can be considered
in our model...has-a, is-a, etc...

Regards,

Greg Copeland