What are the pros and cons of object databases?

Question

There is a lot of information out there on object-relational mappers and how to best avoid impedance mismatch, all of which seem to be moot points if one were to use an object database. My question is why isn't this used more frequently? Is it because of performance reasons or because object databases cause your data to become proprietary to your application or is it due to something else?

Bunco

Answer 1

• Familiarity. The administrators of databases know relational concepts; object ones, not so much.
• Performance. Relational databases have been proven to scale far better.
• Maturity. SQL is a powerful, long-developed language.
• Vendor support. You can pick between many more first-party (SQL servers) and third-party (administrative interfaces, mappings and other kinds of integration) tools than is the case with OODBMSs.

Naturally, the object-oriented model is more familiar to the developer, and, as you point out, would spare one of ORM. But thus far, the relational model has proven to be the more workable option.

See also the recent question, Object Orientated vs Relational Databases.

Fauver

A counterargument to familiarity: if you're persisting the objects which the developers are using, do you still need db admins? Or could you hire more developers who can then split their time between admin and development? – Sammie

A counterargument to performance: berkeleydb; its not relational, and can scale vertically to 256 terabytes. Memcached; its not relational, and can scale horizontally AFAIK indefinitely. – Sammie

A counterargument to maturity: SQL is not long-developed. It is under-developed over a long time. Some would say C is mature because it has been around for a long time. I say C# is mature because it is partly a result of our collective experiences with C. – Been

One reason to go with an object-relational mapper and a relational database is that if you run into performance problems you can fall back to hand-crafted SQL. Database people have been thinking about crunching data for a lot longer than the object-oriented people. The development of SQL has not stopped: the latest version of the standard was 2008. Though there is a long lag time between adding a feature to the standard and implementing it in actual databases. E.g. recursive queries were added in the 1999 standard, but postgresql may be the only one with a working implementation. – Aceves

About performance, the biggest database of the world (1000TB, is for a particle accelerator facility) is OO... – Ashelyashen

Answer 2

I've been using db4o which is an OODB and it solves most of the cons listed:

• Familiarity - Programmers know their language better then SQL (see Native queries)
• Performance - this one is highly subjective but you can take a look at PolePosition
• Vendor support and maturity - can change over time
• Cannot be used by programs that don't also use the same framework - There are OODB standards and you can use different frameworks
• Versioning is probably a bit of a bitch - Versioning is actually easier!

The pros I'm interested in are:

• Native queries - Db4o lets you write queries in your static typed language so you don't have to worry about mistyping a string and finding data missing at runtime,
• Ease of use - Defining buissiness logic in the domain layer, persistence layer (mapping) and finally the SQL database is certainly violation of DRY. With OODB you define your domain where it belongs.

I agree - OODB have a long way to go but they are going. And there are domain problems out there that are better solved by OODB,

Loya

Answer 3

One objection to object databases is that it creates a tight coupling between the data and your code. For certain apps this may be OK, but not for others. One nice thing that a relational database gives you is the possibility to put many views on your data.

Ted Neward explains this and a lot more about OODBMSs a lot better than this.

Cuddy

This is silly. If you don't have this tight coupling, you get to the standard RDBMS error rate of 30% faulty records. – Solange

Answer 4

It has nothing to do with performance. That is to say, basically all applications would perform better with an OODB. But that would also put lots of DBA's out of work/having to learn a new technology. Even more people would be out of work correcting errors in the data. That's unlikely to make OODBs popular with established companies. Gavin seems to be totally clueless, a better link would be Kirk

Solange

The link to Kirk Pepperdine's great blog post is worth the +1 – Geosynclinal

Answer 5

Cons:

• Cannot be used by programs that don't also use the same framework for accessing the data store, making it more difficult to use across the enterprise.

• Less resources available online for non SQL-based database

• No compatibility across database types (can't swap to a different db provider without changing all the code)

• Versioning is probably a bit of a bitch. I'd guess adding a new property to an object isn't quite as easy as adding a new column to a table.

Bibbye

Answer 6

Sören

All of the reasons you stated are valid, but I see the problem with OODBMS is the logical data model. The object-model (or rather the network model of the 70s) is not as simple as the relational one, and is therefore inferior.

Alby

If both are equally powerful, and in this case they are since the relational model can represent anything, then simplicity is better. – Alby

Answer 7

jodonnel, i dont' see how use of object databases couples application code to the data. You can still abstract your application from the OODB through using a Repository pattern and replace with an ORM backed SQL database if you design things properly.

For an OO application, an OO database will provide a more natural fit for persisting objects.

What's probably true is that you tie your data to your domain model, but then that's the crux!

Wouldn't it be good to have a single way of looking at both data, business rules and processes using a domain centric view?

So, a big pro is that an OODB matches how most modern, enterprise level object orientated software applications are designed, there is no extra effort to design a data layer using a different (relational) design. Cheaper to build and maintain, and in many cases general higher performance.

Cons, just general lack of maturity and adoption i reckon...

Vesuvianite