Object Database vs. Relational Database

Related Sites

RDBMS's [... provide] a simple flexible model of the data (based in set theory - however that helps) and a general purpose declarative query language. [...]

ODBMS's [...] provide a relatively much more complex data model and procedural query language to navigate it.

Drew Wade replied that ODBs make the developer's job easier:

The general purpose declarative query language [SQL] was a big step forward, and is continued with ODBMS's, in fact made more powerful, because you can now query not just the primitives (gears, pistons, nuts and bolts), but all the way up to the highest application objects (engine, frame, car), using methods in your query just as if they were built-ins, using relationships the same way, etc.

But the simpler model of the RDB world does not simplify applications, but rather makes them harder. A simple model is good for proving theorems, formal studies, etc. But in the real world, your real-world problem (application) determines the complexity. If your problem is simple, then RDBs work fine (simple, here, means simple, flat, tabular data structures, fixed length fields, no relationships, no traversal, no nested structures, no user-defined structures, no methods, etc.).

As your problem gets more complex, the more complex the worse the RDB approach and the more advantage from the ODB approach. The RDB approach requires the application programmer to map his actual problem objects (entities, relationships, methods, nets, etc.) down to primitives, to do the hard part of the queries himself (mapping them down to flattened primitives), etc. This mapping layer gets bigger, more complex, more error prone, and very hard to maintain whenever you change your object model (which, of course, always happens...).

With the ODB approach, whatever your application objects are, they are taken as-is by the ODB. Just define them in C++ or Java or Smalltalk (or use a higher level declarative modeling language like ODMG's ODL), and the ODBMS takes it from there. All the need for mapping code, disassembling into flattened primitives, translating queries down to primitives, etc., goes away. The maintenance problem goes away, too, as the mapping code goes away. Just change your types as you like, and the ODBMS schema evolution facility automatically manages the changes for you, updates instances of old types to new ones, can work online, etc.

It's quite common for us to see customers with 1/3, even 1/2 of their application consisting of such mapping code. When they convert to ODBMS, they throw away the mapping code, reducing the complexity of their application, making it more robust, more flexible/changeable, reducing maintenance, etc. Not to mention that they can now write 30-50% more applications. :) (Caveat: although some report this very quickly, for others the learning curve takes time. If you don't know objects, plan learning time. if you already do, adding the ODBMS is minor.)

In short, the complexity is determined by your application. If the DBMS model allows you to model that complexity directly, it will be much easier. If not, expect to budget more work, more maintenance.

[...] The relational model, as implemented in most RDBMSs, can represent a lot of different models, but has difficulty representing inheritance hierarchies, and complex relationships (many many-to-many's) are costly to process.

[...]

The schema in an ODBMS matches (and is typically derived directly from) the class definitions in the application. [...] Objects can "navigate" or traverse these relationships to other objects and have those other objects automatically brought into application memory, without additional coding -- the ODBMSs support a client side object cache [...]. Once in memory, repeat traversals occur at in-memory speed and there is no need to re-query the database for the object. This allows for building complex relationships between objects -- the heart of many- to-many relationships -- and rapid, high speed navigation between them because they do not need to be computed on the fly (like SQL Joins). Hence there is a significant performance difference for complex models, often a factor of 100x-1000x vs. relational databases for similar data models. [...]

(ootips) Storing Objects in a Database

Akmal B. Chaudhri, Choosing a Strategy for Object Data Management: Relational, Object or Hybrid?

POET Software, Why Use an ODBMS?

Barry & Associates, Object DB articles