Re: Decline of Science: Computer Science and Databases

Leandro Guimarães Faria Corsetti Dutra wrote:
> > No, I did mean table inheritance, since I think table inheritance
> > would be necessary, to represent object oriented languages correctly.
>
> Data is data. Programs are something else. If you want to represent
> programs in a database, this has nothing to do with OO. Now if you want
> to overcome the so-called OO-RM "impedance mismatch", please read The
> Third Manifesto. You will see that type inheritance thru S by C is
> needed indeed, and a relvar is also a type. So that's it.
>
> Now, if you think something else is required, please enlighten us.

Yes, I do think that table inheritance is required.

A sample out of practice, simplified for brevity:

class Contract(){
  String name;
  Position[] positions;
  // 30 other members typical to all contracts }

class BuildingEngineeringContract extends Contract(){   // 30 building engineering specific members }

class ServiceContract extends Contract(){   // 30 service specific members
}

class Position(){
  String description;
  double amount;
  // 15 other members for tax, currency
}

class BuildingEngineeringPosition extends Position(){   // 10 members specific to building engineering }

class ServicePosition extends Position(){   // 10 members specific to building engineering }

Now I want to use one-and-the-same code to sum up over positions, to create reports by date, to calculate and to update budgets. In these reports I may also need the information specific to the derived types. How would I do it?

The above is just a very small portion from the different types of contracts and positions that we needed. Further to "BuildingEngineering" and "Service" there were 30 more generic/specific types and a lot of vertical inheritance hierarchies between them.

Without table inheritance, there are two approaches:

(1) Store all position attributes in one large table. The table has more than 300 columns and it is completely unmaintainable. Performance is dreadful and one position only uses up one tenth of the space allocated for a row. It is not possible to use indices on type-specific data, since the database would explode immediately.

(2) Use relations for data specific to special types. Queries turn out to be a mess. Either you work with many, many different queries for every single inherited type, or you have one huge query with 30 outer joins. The relations make the system terribly slow.

Houston, I think the problem is on your side.

Take the above, put it into an object database and it will tell you "Hey great, this is fun, this is what I was built for."

Add further derived classes at you own wish, when you need them and CONTINUE to use all existing query code without a single modification.

No how would you do this in a relational system?

Kind regards,
Carl

--
Carl Rosenberger
db4o - database for objects - http://www.db4o.com