Multiple inheritance in the Oracle database

Zlatko Sirotic

Bertrand Meyer (author of OOPL Eiffel (1985), professor at ETH Zurich) in his book Object Oriented Software Construction (1997) writes (page 533):

"Multiple inheritance is indispensable when you want to state explicitly that a certain class possesses some properties beyond the basic abstraction that it represents.

Consider for example a mechanism that makes object structures persistent (storable on long-term storage)

... The discussion of inheritance methodology will define it as inheritance of the structural kind.

Without multiple inheritance, there would be no way to specify that a certain abstraction must possess two structural properties — numeric and storable, comparable and hashable.

Selecting one of them as the parent would be like having to choose between your father and your mother."

In the Java world it has long argued that multiple inheritance is a bad thing.

For example, this is from the (excellent) book Head First Java (2005, page 223):

"It's called "multiple inheritance" and it can be a Really Bad Thing.

That is, if it where possible to do in Java.

But it isn't, because multiple inheritance has a problem known as The Deadly Diamond of Death".

(Note: Bertrand Meyer solved this problem in Eiffel, at the beginning:

"A class that inherits from one or more others gets all its features, by default under their original names.

It may, however, change their names through rename clauses. This is required in the case of multiple inheritance if there are name clashes between inherited features.")

But finally, Java 8 introduced a certain form of multiple inheritance - default methods in the Java interfaces.

Maybe it is time to make multiple inheritance in the Oracle database?

To begin with something like in Java 8 - the ability to inherit the attributes of a single class, but the ability to inherit the (non-abstract) methods of multiple classes.

Sven W.

I'm not realy sure what the "idea" here is.

In the SQL world an object class is called a table. An instance of this object would be a row in the table.

Multiple inheritance is nothing else than having multiple foreign keys pointing to different rows in some parent tables.

William Robertson

Perhaps some sample syntax and a real-world use case would make it easier to see the advantages of this proposal.

In PL/SQL we currently have:

   create or replace type waterpistol under weapon (

      overriding member procedure reload

   );

and your suggestion is to extend the syntax to allow it to inherit selected attributes and methods from "toy" as well.

I'm all for extending PL/SQL object capabilities, but I can't help feeling this would just introduce a load of complication without significant benefit.

Lukas Eder

"Multiple inheritance is indispensable when ..."

I'd even claim that "single inheritance" is a horrible thing. Those people in the 90s really went way too far on object orientation. Certainly, adding more inheritance capabilities in PL/SQL won't help. I even doubt a lot of people use single inheritance extensively through PL/SQL OBJECT types.

William Robertson

"Multiple inheritance is indispensable when ..."

I'd even claim that "single inheritance" is a horrible thing. Those people in the 90s really went way too far on object orientation. Certainly, adding more inheritance capabilities in PL/SQL won't help. I even doubt a lot of people use single inheritance extensively through PL/SQL OBJECT types.

I have been using object types recently as I had a set of ETL tasks to write that all followed the same pattern, and it's been a revelation. Maybe I should have used them more in the past. I'm not sure multiple inheritance would have helped but perhaps I am missing something.

What's wrong with subclasses?

Gerald Venzl-Oracle

Thanks for your contribution!

I struggle to see an actual idea, enhancement or current issue in this DB idea. Can you please explain further what your use case is or which issues you are currently facing?

Lukas Eder

I have been using object types recently as I had a set of ETL tasks to write that all followed the same pattern, and it's been a revelation. Maybe I should have used them more in the past. I'm not sure multiple inheritance would have helped but perhaps I am missing something.

What's wrong with subclasses?

After a lot of experience in object orientation, many people have concluded that composition (as in functional programming) should be favoured over inheritance:

https://en.wikipedia.org/wiki/Composition_over_inheritance

In fact, there are some modern languages that do not implement subtype polymorphism at all (which is controversial but interesting).

In any case, most people agree that multiple inheritance of state is one of the things that made C++ so incredibly complicated while not really adding a lot of value.

William Robertson

After a lot of experience in object orientation, many people have concluded that composition (as in functional programming) should be favoured over inheritance:

https://en.wikipedia.org/wiki/Composition_over_inheritance

In fact, there are some modern languages that do not implement subtype polymorphism at all (which is controversial but interesting).

In any case, most people agree that multiple inheritance of state is one of the things that made C++ so incredibly complicated while not really adding a lot of value.

I can't say I am much the wiser after looking at the Wikipedia entries on composition. Is it any good?

Lukas Eder

I can't say I am much the wiser after looking at the Wikipedia entries on composition. Is it any good?

Well, I guess there are simpler explanations than that article...

Zlatko Sirotic

I'm not realy sure what the "idea" here is.

In the SQL world an object class is called a table. An instance of this object would be a row in the table.

Multiple inheritance is nothing else than having multiple foreign keys pointing to different rows in some parent tables.

> In the SQL world an object class is called a table.

Wrong. This, obviously, is not a table:

CREATE TYPE address_t AS OBJECT (

  city VARCHAR2(20),

  street VARCHAR2(30)

);

> An instance of this object would be a row in the table.

Partly true. An object can be an entire row, or a column (here):

CREATE TABLE person (

  name VARCHAR2(40) PRIMARY KEY,

  address address_t

);

> Multiple inheritance is nothing else than having multiple foreign keys pointing to different rows in some parent tables.

Very wrong.

Sven W.

> In the SQL world an object class is called a table.

Wrong. This, obviously, is not a table:

CREATE TYPE address_t AS OBJECT (

  city VARCHAR2(20),

  street VARCHAR2(30)

);

> An instance of this object would be a row in the table.

Partly true. An object can be an entire row, or a column (here):

CREATE TABLE person (

  name VARCHAR2(40) PRIMARY KEY,

  address address_t

);

> Multiple inheritance is nothing else than having multiple foreign keys pointing to different rows in some parent tables.

Very wrong.

I think you misunderstood me. I'm not referring to the OO-add ons in the database. i'm referring to SQL itself.

It seems you are trying to enforce certain principals that exist in the object oriented world into SQL. This usually doesn't make sense. SQL is a 4th generation language.  Plsql, java etc. all are 3rd generation. We need to switch from thinking in a procedural way when dealing with SQL.

In a 3rd GL we are telling how a certain goal should be archieved and programming the steps to reach that goal.

In 4th GL (=SQL) we build a model and only formulate a question. Then the engine will find out the needed steps to give us the answer to  our questions.

"multiple inheritance" is something that we simply would build into our model. Typically it is done by using a kind of super-type/sub-type entities (and there are many different ways to model such a relation).