|
Posts: 135 / Nickname: fsommers / Registered: January 19, 2002 7:24 AM
Next-Generation Object-Oriented Databases
May 9, 2008 0:00 PM
|
|
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.html What do you think of db4o and the second generation of OO databases? |
|
Posts: 1 / Nickname: tim08 / Registered: May 24, 2008 6:27 AM
Re: Next-Generation Object-Oriented Databases
May 24, 2008 11:44 AM
|
|
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?
|
|
Posts: 1 / Nickname: zqudlyba / Registered: January 30, 2007 7:46 PM
Re: Next-Generation Object-Oriented Databases
May 12, 2008 0:50 AM
|
|
DOA - Dead on Arrival.
|
|
Posts: 37 / Nickname: miata71 / Registered: March 29, 2006 6:09 AM
Re: Next-Generation Object-Oriented Databases
May 12, 2008 8:18 AM
|
|
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.
|
|
Posts: 1 / Nickname: rgreene / Registered: May 25, 2008 11:21 PM
Re: Next-Generation Object-Oriented Databases
May 26, 2008 4:31 AM
|
|
Why?
|
|
Posts: 4 / Nickname: articulate / Registered: September 19, 2005 8:54 AM
Re: Next-Generation Object-Oriented Databases
May 26, 2008 5:45 PM
|
|
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. |