Summary:
Object-oriented databases complement relational databases in important ways, says Anat Gafni, VP of Engineering at db4objects, the company behind the open-source object database db4o. In this interview with Artima, Gafni explains how OO databases support agile development, and how they co-exist with relational databases in an enterprise.
The ability to add new comments in this discussion is temporarily disabled.
Most recent reply: May 26, 2008 5:45 PM by
art
|
|
In this interview with Artima, Gafni explains how OO databases support agile development, and how they co-exist with relational databases in an enterprise: http://www.artima.com/lejava/articles/javaone_2008_anat_gafni.htmlWhat do you think of db4o and the second generation of OO databases?
|
|
|
|
|
|
|
Even though I've grown fairly comfortable with Spring/Hibernate and it's quirks and issues, (a co-worker does all the hard work and SQL queries) I used db4o on a small prototype project and thought it was even better than sliced bread.
|
|
|
|
|
Nice post. As a zope developer I am aware of the advantages of using an object database and I am looking forward to trying db4o. Currently however I am interested in google's 'big table' which is probably more like an object database than a relational database (schema changes are easy). db4o is aimed at the java/c# crowd. That is probably a good marketing choice but they usually work in conservative environments (eg. fortune 500). Slow adoption. Zope is getting ported to jython. I wonder if db4o would out perform zodb in a jython version of zope?
|
|
|
|
|
|
|
In most of the enterprise application I have been involved with, interaction with an SQL client/server DB has been a big time suck during development. It is also the most likely cause of performance issues.
At least if you get a DB with MVCC (Multi Version Concurrency Control) you don't get chronic deadlocks.
The ORM tools are complex, buggy, and incomplete. In practice the object model has always been seriously compromised by mapping to a relation database.
ORM can't work in general with a remote data store. Distribution boundaries don't disappear, databases are remote, and "don't distribute objects" is a solid principal for software architecture.
Deployment to the database has been the most problematic part of the deployment process.
There is plenty of scope for improvement on the status quo. I don't know if db4o or NGOODB's are the answer, but not solving the problem consigns us to the enormous amounts of wasted developer hours, and dramatically increased time to market for enterprises.
I am not giving up on the idea that there is something better than SQL + JPA.
|
|