> I don't see any purpose to multiple inheritance in the semantic world.
> I'd go further and say that multiple inheritance is almost any domain is
> one of mother nature's gentle ways of telling you that your application
> design is lousy. C++ has it, Java doesn't (uses interfaces instead),
> and Java is the better language for it. There are lots of other pieces
> of OO baggage that people want to hang off the semantic model that
> should be resisted.
>
> So, single parent, primary key must be defined in the base table, other
> indexes defined in the type hierarchy as needed, and no sex change
> operations. Simple, elegant, and to the point.

The only difference I see between C++ multiple-inheritance and Java interfaces is that in Java, you
have to pick zero or one interfaces from which to inherit a set of method implementations, while
C++ allows you to inherit zero to infinity of them. Considering how widely modern Java projects use
the multiple-interface idiom, I would argue against using Java as proof that multiple inheritance
is dead, useless, wrong, or unhelpful. It may be any or all of those, but Java isn't the proof you
seek.

(If you do truly need MI in Java, and you don't want to re-implement all but one of the classes
you're trying to extend, you wind up having the same problem we're discussing with MI in the
database, the problem of identity: you'll create a class that implements two interfaces [one
derived table], contains two attributes that themselves are instances of concrete classes that
implement those interfaces [two base tables, and foreign keys to them in the derived table], and
you'll write all the logic to proxy calls through your interfaces into your attributes [instead-of
triggers to make the derived view updatable], each of which has its own identity and must be
careful not to report its own, rather than that of its container, in any of its dealings with other
objects [pk on the derived table vs. pk on the two base tables].)

Splitting a set of tables up so common attributes are stored in common may add to the complexity of
the database, but in my mind, it adds to the semantic value of the database as well. Rather than
trying to push everything that shares any equivalent attributes into one unifying hierarchy of
entity types to avoid dealing with identity issues, you use the relational model to your advantage -
- you can extend anything in any direction at any time, by just creating new relations. If tables
X, Y, and Z all share a few fields, why not split those into a separate table so it's obvious that
those fields really are equivalent to each other? The danger is that you do that once, and it's
inheritance and acceptable; do it twice, and it's MI and "bad". If we're afraid to do this, when
companies A and B get together to determine what information they have in common, it'll be hard to
see that "oh, yes, tables A.X and B.Y are essentially the same concept" because they won't exist --
they'll be part of tables A.Z, A.W, B.P, etc., right along all sorts of indirectly-related stuff.
The mapping will be that much harder, and the data-cleanup, and the risk of breakage when someone
makes metadata changes, ...

I encourage you not to abandon the idea.

-Philip