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,
answered 2008-10-05T07:01:38.350