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?

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.

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,

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.

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

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.

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.

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...