Can object oriented databases be a better option t

Question

Just thinking that a relational db with an ORM is in many ways very similar to an object oriented database. My experience lies solely with RDMS with a hint of ORM, so it seems to me that object oriented databases are very similar but without the experience I can't say for sure.

If you have used object oriented databases and ORMs can you compare them? What are the weak points associcated with object oriented databases compared to RBMS+ORM?

Answer 1

Chris Date agrees:

... 'object/relational' system would be nothing more nor less than a true relational system ... A proper object/relational system is just a relational system with proper type support ... which just means it's a proper relational system, no more and no less.

SQL and Relational Theory: How to Write Accurate SQL Code, p 36

Answer 2

What are the weak points associated with object oriented databases compared to RBMS+ORM?

The biggest weakness is the lack of standardization: no standard API, no standard query language (the OQL attempt has been a big failure) and thus the lack of portability and interoperable tools (for backup, archiving, migration, etc). You don't want that when it comes to data.

This explains IMO why OODBMS are a failure from an adoption point of view and why RDBMS will stay around for a while, regardless of the NoSQL movement (I have the feeling that OODBMS vendors see the NoSQL movement as an opportunity for a come back after some rebranding of their products).

Answer 3

My experience:

• RDBMS:
  • Frankly, I don't like working with SQL, a 15-year old language, but the reality is that you're forced to if you want anything usable, such as bulk inserts (the LINQ-to-Entity ORM framework does not support bulk inserts, so it takes 30 seconds for a 20,000 record insert, compared to 500ms for a bulk insert in SQL). You end up having to use ADO.NET for database insertions.
  • There are some advantages of an RDBMS over an object database, namely, the data is independent of the calling application (however, this is a weakness also, as the mapping layer makes everything slower, more complex, and more brittle).
  • Bottom line: Spent 6 weeks with the LINQ-to-Entity ORM framework and Microsoft SQL Server 2008 R2. Reasonably steep learning curve.
• Object databases: Tried an object database, namely, the free, open source db4o.
  • Discovered that I could persist my objects with one line of code.
  • No schema changes to deal with, it just worked.
  • Instant support for POCO (Plain Old Class Objects). Create your class in code, then persist it. Its possible to do the same with the Entity framework, however, its a lot of work with manual mapping, and it breaks very easy.
  • Turn on transparent persistence, and it has automatic lazy loading in the background - no more checking for objects that are not loaded because of lazy loading in the Entity framework.
  • The performance of object databases is also impressive: if you have 10 million rows in an object database, and indexing turned on, its 16ms for a three-column select. That's decent.
  • Bottom line: After 1 week I had the same solution as using a RDBMS for persistence, however, it was much cleaner, much less code, and more maintainable - and if I really wanted, I could use use a service to synchronize the db4o database with MSSQL.

For really large systems in the enterprise world, consisting of say 250 million rows in a table, things like sharding and options such as clustered indexing vs. non-clustered indexing become important for performance. In this case, db4o wouldn't work, it may require something more enterprisey. However, if you a trivially easy method of persisting objects, then an object database will fit the bill. All the work of learning SQL, setting up the mapping in the ORM, dealing with installation of MSSQL, implementing your own bulk loading procedures, etc just disappears, leaving you with clean, elegant 100% managed code.

I suspect that one of the reasons that vendors have not embraced object databases as that the database market is worth $3 billion per year, and there is no reason to kill the cash cow just yet.

Disclaimer: I have no affiliation with either Microsoft or db4o.