For many years now we always seem to have been on the verge of the revolution in object databases, without it ever quite transpiring. No-one should be holding their breath on the disappearance of the relational database. At the same time, the object database issue will never quite go away, due to the fervent desire of some developers to avoid using relational databases unless they really have to.
This is a manifestation of the YAGNI (You Ain't Gonna Need It) principle that emerged from the bowels of the Extreme Programming movement. It refers to the idea that you should only add a feature if there is an immediate need for it, not because you can predict a future need for it. Some advocates of Domain Driven Design (DDD) apply this principle to the relational database. DDD adopts a silo-based approach focussed solely on the business domain that a particular application represents and tries to implement an entity model that directly reflects what the business sees, rather than some 'compromised' version of this, imposed by the constraints of working in harmony with the underlying relational database.
Unfortunately, however warm and cozy it feels within the realm of their pure business entities, they know that the light at the end of the tunnel is the headlamp of the train that is the relational data model to which they will have to meld their entities. The knowledge of the impending impact is ever-present and they wish to avert it, or at least lessen its impact.
After all, why does one need a huge relational database engine to "persist" the data required to guide users through their application? Object databases are becoming ever more powerful, they now work with stored procedures to keep DBAs happy and, of course, they fit far more readily into the world of their entity business models. Surely, the majority of their application processes could easily be driven by an object-oriented database, resorting to a relational database only to store that data required for business reporting?
This is "relational database YAGNI". However, it is proving to be the proverbial itch that cannot be scratched. Despite the understandable allure of object databases, they have remained resolutely out of reach of the mainstream. Why is this? After all, it has found a place in a few industries, such as telecoms, and the largest database underpins the Stanford linear accelerator system, and it's an object database, so there seems to be no issue with scalability.
The problem is fundamental. Relational databases strongly reflect the inherent nature of the business and accounting applications that we have been developing over centuries. A ledger is essentially a database table. There is a strong, probably unbreakable, connection between the world of commerce and the relational database. It is also no accident that the most widely deployed database engine in the world, SQLite, is a relational one, and powers the likes of the iPod, FireFox3, Nokia's Symbian platform and several others. The data needed to drive such applications and platforms is essentially relational in nature, and needs to be subject to SQL-style data definition and manipulation.
It is for this reason that object databases are destined to be always "next year's technology".
Cheers,
Tony Davis (Guest editor)
