I’ve been playing with Nordic (New Object/Relational Design) for a few years, but this year I began to work on a product app using Nordic which was the impetus for beefing up the API. The Nordic 2.0 API and a .net front-end app will be launched at SQL Teach in Vancouver Nov 28th.
I’ve presented Nordic to about 20 user groups and conferences over the past few years. At nearly every presentation someone will ask about multiple inheritance. It’s a good question. In my production app, I’d love to define an object that includes properties from both Major Donor and Volunteer. Perhaps due to my ignorance, I’ve always looked at multiple inheritance as an object that belongs to multiple classes. While that could be done, it seems a bit complex. The currnen Nordic API supports morphing an object from one class to another (a necissary feature for any Object/Relational solution), but the Nordic schema is a far cry from defining an object using multiple classes. The most basic assumtion is the every object is defined as belonging to a single class.
Another possible way to extend an object with properties beyond its class is to define optional roles for a class. This would permit any Donor, for example, to also have attributes of a Major Donor role and the Volunteer role simultaneously. Very cool idea suggested to me by Wolfgang Baeck. I think I’ll add this feature in a future version.
But back to multiple inheritance, while mindlessly browsing the net the a few nights ago I was completely shocked to read that Cache (an object database that claims to be 10-15 times FASTER than any relational database !?!?) supports multiple inheritance. They define multiple inheritance as a single class that inherits from multiple classes. Their example is a Dog class that inherits from both the Mammal and Pet classes.
Now That I can do.
Nordic's current Class metadata table has a SuperClassID which defines the hierarchy of classes. Two functions, SuperClasses(), and Subclasses() navigate the class structure and provide the list of classes for other queries that return the list of attributes that apply to a class or the subclasses for selecting all objects of a given class including subclasses.
Using a SuperClass table to store a many-to-many relationship between classes (like a BOM) is a trivial change. The same to function once refactored can return the superclasses including the multiple inheritance classes. The code generation will then automatically include the additional columns and cascading call tables in the code generated class APIs and tada - multiple inheritance.
I love SQL – any data solution that can be dreamed can be built in SQL.