You're describing here a design rule able to emulate an heritage, which is mostly a matter of methodology/dba experience.

With a (real) OODBMS, this kind of *trickery* relational modelisation is not required.

Well and good to use an OODBMS if one is within your options. I make no assertions about whether an RDBMS or OODBMS is more appropriate.

However I will not allow it to be said RDBMS do not support ISA relationships, when they are clearly supported and the relationship follows directly from normalization. It is not trickery, nor even unusual.

Update: Removed inflammatory language that was not meant to be so.

However I will not allow it to be said RDBMS do not support ISA relationships, when they are clearly supported and the relationship follows directly from normalization.

Wrong. That is completely and utterly wrong. RDBMSes support HAS-A relationships, in that a lineitem record HAS-A invoice record that it is on. Set theory (which RDBMSes are based on) is all about HAS-A relationships. The only IS-A relationship is the relationship between the specific record and the table it lives in. The person you are attempting to lay the smack-down is absolutely correct.

You might do well to rethink exactly what an IS-A relationship is vs. a HAS-A relationship and how normalization works with that.

------
We are the carpenters and bricklayers of the Information Age.

Then there are Damian modules.... *sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon. - flyingmoose

I shouldn't have to say this, but any code, unless otherwise stated, is untested

I think we are not using the word 'supports' in the same manner. Allow me to clarify my definition with a contextual example. RDBMS support ISA relationships like Perl 5 supports OO programming.
--Solo

--
You said you wanted to be around when I made a mistake; well, this could be it, sweetheart.