Re: Inheritance - Mailing list pgsql-hackers

On Fri, 2002-09-06 at 09:53, Curt Sampson wrote:
> 
> If the language specifies that contstraints on tables are not to be
> violated, then don't use those constraints when you don't want them.

But what _should_ i use then if i want the same business rule on most
top-level types, but a changed one on some down the hierarchy ?
> > 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.
> 
> This looks like a classic case of incorrect modelling to me. Does the
> good itself change when it becomes a campaign_good? No. The price
> changes, but that's obviously not an integral part of the good itself.

Perhaps we mean different things by good. I meant a GOOD to be a THING 
bought with the purpose of reselling. Price (actually prices: 
selling_price and buying_price) is what makes it a GOOD and thus it is
an integral part of it.

> So separate your price information from your good information, and then
> you can do things like have campaign prices, multiple prices per good
> (since you probably want to keep the original price information as
> well), and so on.

It does not solve the problem described above - the price at which the
good is soled is still constrained differently for orninary and campaign
goods.

in standard relational model you would make the distinction inside the
constraint (CHECK (selling_price > buying_price) OR is_campaign_good)
but this localises the check in wrong place - in OO model I'd expect it
to be possible to define the constraint near the child type, not change
the parent constraint each time I derive new child types.

> I'm really getting the feeling a lot of these applications that
> want table inheritance want it just to be different, not because
> it provides anything useful.

As with any other inheritance, it is just a way to organize stuff.

In case of being able to override constraints for child tables it can
also be a significant performance boost - if you have 10 000 000 goods
in a table you don't want to change a constraint on GOODS to allow
campaign goods to be sold cheaper than bought as it would have to check
all goods for validity according to new constraint - putting the
constraint on just CAMPAIGN_GOODS will enable the DB engine to check
just tuples in CAMPAIGN_GOODS.

> I am completely committed to object-oriented programming, and use
> inheritance heavily, so it's not that I don't understand or like the
> concepts. But just because a concept works well in one type of use does
> not mean it will do any good, or even not do harm, when brought into a
> completely different world.
 Surely great caution is needed when defining the desired behaviour.

> > SQL standard constraints should be non-overridable. I still think that
> > Constraint triggers should be overridable/dynamic.
> 
> I still don't like it. Eiffel had good reasons for making the
> constraints non-overridable. Other OO languages don't have constraints,
> or they would probably do the same.
> 
> That said, I could live with dynamic dispatch, if the default were
> to make it non-dynamic, and you had to add a special flag to make it
> dynamic. That way it would be obvious to the casual user or a DBA
> familiar with other databases but not postgres that something unusual is
> going on.

That seems about the right compromise between constraining and developer
freedom.

-------------
Hannu