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
signature.asc
Description: This is a digitally signed message part
