Zen and the art of ODBMS
I think it isn't really difficult to see: I'm a fan of object-oriented database management systems. But how does it come, why do I appreciate them so much and how do I compare them to relational database management systems and object-relational mappers?
If I remember right my fiirst steps in object-orientation begun in the late 1980s. I've read about Smalltalk, Objective-C and C++. But licenses had been expensive, and powerful machines too. In 1989 Borland released Turbo Pascal 5.5 which had some OO features. This software allowed me to do my first practical steps in object-oriented software development. And I really must say that I've liked it from the first day. The concept of designing and programming construction plans for "living" objects inside the system, that have states and communicate with each other, has been so natural for me that I do OOP until today. So it is no surprise that I also followed the database market and read about ODBMS. I found this idea a logical continuation of the OO paradigm.
In 1999 I've gotten the chance of leading a software development team implementing a content management system based on J2EE. I've tested the usage of ODBMS a short time before using the ObjectStore PSE for Java. So in this project we evaluated some persistency strategies and systems and we decided us for using POET. We had no mass data with a high query load. But our idea has been to store XML in a parsed DOM tree directly inside the database. The elements inside the documents could be regular elements or dynamic elements. Those have been executed for including other documents or querying external databases or data sources before being rendered via XSL-T and then delivered.
Here you allready see one of the major domains for ODBMS. When object structure are complex, maybe hierarchical, and there are no complex queries but an access via identifiers and then through the navigation over the networked objects, then you're right with ODBMS. The entry point is typically a registered root object, often a collection. Dictionaries or b-trees allow the access via a unique key. Also there may be different kinds of entry points, depending on the business case. So customers could be accessed via their customer number but also via a reference inside an invoice retrieved by the invoice number. Tight meshed objects allow a large number of possible navigation paths. This allready shows one disadvantage: all those references have to by maintained by the application. But in relational databases foreign keys have to be maintained, too. So the overhead is tolerable.
Another great plus is that no mapping is needed. Depending on the ODBMS the persistent classes may need to be derived from a special base class, or they need an anotation. Other systems - like our Tideland SOS - handle the persistency totally transparent for the developer. This also applies to the CRUD operations. Depending on new added instances to the network of other persistent objects, navigating between them, changing the values of instance variables or just set them to nil all operations are handled automaticly. The only needed actions are beginning a transaction, navigating starting at a root object, and committing or aborting the transaction. So an ODBMS presents itself as a large persistent extension of the main memory.
OK, ODBMS naturally also have disadvantages. They differ from vendor to vendor. So I just list them.
- The support for queries (e.g. with OQL) is often bad.
- The access through different languages often is difficult.
- Schema evolution sometimes isn't supported very good. OK, that's hard for RDBMS based apps too.
Our Tideland SOS has a tight binding to Smalltalk, queries are only provided by the typical methods like select and schema evolution is currently only supported for additional instance variables and classes. But the concept for more is allready outlined. But it depends on your needs. Our ODBMS is a very lightweight system for small to mid-sized applications.
How about O/R mapper? Hmm, I don't really like them. The mapping, even if it is tool supported, so much additional configuration files, often in XML, not as flexible as ODBMS. Maybe I've just made my experiences with a wrong designed system (about 750 classes managed via TOPlink). But when the usage of an RDBMS is needed - customer constraints, legacy data, application integration, OLAP systems - I prefer patterns like the table data gateways and data transfer objects. Here you also see one of the great advantages I see in RDBMS.: they are query optimized. So if an application system heavily relies on data retrieval relational databases are best. Also if an access through different languages - object-oriented or not - and existing apps is needed they do a really good job.
Does an answer to the question "What is the best persistence strategy?" exist? Hmm, I don't think so. It really depends, see above. But if I'm asked for my favorite, I would answer: ODBMS. *smile*
Filed under //
database
development
Comments [0]