Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

What are the pros and cons of object databases?

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?

like image 789
Kevin Pang Avatar asked Sep 14 '08 18:09

Kevin Pang


2 Answers

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

like image 81
Sören Kuklau Avatar answered Oct 13 '22 11:10

Sören Kuklau


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,

like image 20
Goran Avatar answered Oct 13 '22 10:10

Goran