On Mon, 2002-08-12 at 10:39, Oliver Elphick wrote:
> On Mon, 2002-08-12 at 15:00, Greg Copeland wrote:
> > How exactly would you create an abstract base class for table type?
>
> CREATE TABLE abstract_base (
> cols ...,
> CONSTRAINT "No data allowed in table abstract_base!" CHECK (1 = 0)
> )
>
> This assumes that the constraint is not inherited or can be removed in
> child tables.
>
Why would I assume that constraints would not be inherited? Seems as a
general rule of thumb, you'd want the constraints to be inherited. Am I
missing something?
Also, if I remove the constraint on the child table, doesn't that really
mean I'm removing the constraint on the parent table? That would seem
to violate the whole reason of having constraints. If a constraint is
placed in an ABC and we find that we later need to remove it for EVERY
derived class, doesn't that imply it shouldn't of been in there to begin
with? After all, in this case, we're saying that each and every derived
class needs to overload or drop a specific constraint. That strikes me
as being rather obtuse.
That, in it self, I find rather interesting. Is there any papers or
books which offers explanation of how constraints should handled for
table inheritance?
Greg