Re: Inheritance - Mailing list pgsql-hackers

> On Fri, 2002-09-06 at 07:37, Curt Sampson wrote:
> > On 5 Sep 2002, Hannu Krosing wrote:
> > 
> > > Suppose you have a table CITIZEN with table-level constraint IS_GOOD
> > > which is defined as kills_not_others(CITIZEN). and there is table
> > > CIVIL_SERVANT (..) UNDER CITIZEN. Now you have just one table MILITARY
> > > (...) UNDER CIVIL_SERVANT, where you have other criteria for IS_GOOD....
> > 
> > This I very much disagree with.
> > 
> > In most object-oriented languages (Eiffel being a notable exception, IIRC),
> > you can't specify constraints on objects. But in a relational database,
> > you can specify constraints on tables, and it should *never* *ever* be
> > possible to violate those constraints, or the constraints are pointless.
> 
> That's not how real world (which data is supposed to model) operates ;)
> 
> As Greg already pointed out, there are two kinds of constraints -
> database integrity constraints (foreign key, unique, not null, check),
> which should never be overridden and business-rule constraints which
> should be overridable in child tables.
> 
> one can argue that the latter are not constraints at all, but they sure
> look like constraints to me ;)
> 
> To elaborate on Gregs example if you have table GOODS and under it a
> table CAMPAIGN_GOODS then you may place a general overridable constraint
> valid_prices on GOODS which checks that you dont sell cheaper than you
> bought, but you still want sell CAMPAIGN_GOODS under aquiring price, so
> you override the constraint for CAMPAIGN_GOODS.

What that tells me is that the constraint, valid_prices, shouldn't have been 
on GOODS in the first place.  If it is not a legitimate constraint for the 
children, then it is not a legitimate constraint for the parent.

In human inheritance, if you marry someone with "funny coloured skin," you 
don't get to choose that your children won't have "funny coloured skin."  
That's a pretty forcible "constraint."  :-).

For the GOODS situation, the constraint ought not to be on GOODS in the first 
place.  There ought to be a table ORDINARY_GOODS, or some such thing, to which 
the constraint applies, and from which CAMPAIGN_GOODS will _not_ be inheriting.

> > So if I have a constraint that says, "no rows appearing in this
> > table will ever violate constraint X," and then you go and create
> > a way of inserting rows into that table that violate that constraint,
> > I think you've just made the database into a non-relational database.
> 
> SQL standard constraints should be non-overridable. I still think that
> Constraint triggers should be overridable/dynamic. 
> 
> Or maybe it is better to just make the check function should be
> dynamically dispatched, so the constraint will always hold, it just can
> mean different things for different types.

Or maybe if someone is doing an Object Oriented design, and making extensive 
use of inheritance, they'll need to apply constraints in a manner that allow 
them to be properly inherited.
--
(concatenate 'string "aa454" "@freenet.carleton.ca")
http://cbbrowne.com/info/
If a cow laughed, would milk come out its nose?