Open Discussion Thread: "Best Practices for Object/Relational Mapping and Persistence APIs"
This an open discussion thread for the developer.* article "Best Practices for Object/Relational Mapping and Persistence APIs," by Mario Van Damme. If you haven't already, you can read it here, then add your comments below.
Why object databases didn't deliver
My personal feelings are that object databases have failed to come out of the academic atmosphere into the commercial arena because they had to compete with a very mature market : the RDBMS market.
This means that in fact, you are comparing the 'qualities' of a new technology with the 'qualities' of a very mature technology. The latter doesn't have any child deceases - or at least no undocumented ones -, while any new technology that you introduce will still have to go through this learning process.
One of those deceases is performance & reliability and - last but not least a very important one - standardisation.
Lack of standardisation, a very competitive market together with the fact that apples were not always compared with apples are the root causes for the failure of object databases.
The consequence of this all is that most object database vendors have disappeared or have refocused their activities.
I currently don't see any sign of a new revival of the object databases. In a way the situation is similar to speech technology : While some years ago everybody got wild about it, it didn't deliver as expected (business-wise). Whether it was for good reasons or for bad, commercial companies consider it a very dangerous investment.
Relational Inertia
I agree with the sentiment expressed above by "Guest" that an object database would eliminate the need for an object/relational mapping scheme, but I think this opportunity is fairly rare. The fact is that even if a programmer/designer/product manager were to try selling an object database as a solution to management/stakeholders, the highly entrenched and safe choice of an RDBMS is going to win out almost every time. Some years ago, when the object database debate was hot, some people might have tried this uphill climb, but I'd be surprised now if anyone would bother trying. The conventional wisdom seems to be that object databases had their chance, but the market rejected them.
I'm sure that's an oversimplification. No doubt there are exciting things happening somewhere with object databases, but it's not a mainstream discussion at the moment. I suspect that the only way that object databases will overcome relational inertia in terms of not only market share but also mind-share is if a really good open source object database manages to make inroads with web developers, in the way that techologies like PHP, MySQL, Rails, etc. have.
If there's enough enthusiasm and the right kind of adoption patterns, ODBMS's might be able to come bottom up into the enterprise. I suspect some kind of symbiotic and force-multiplying tool linkage will be key: for example a web site framework or programming language that is tightly integrated with an object database such that development productivity, clarity, maintainability, etc. are increased enough to attract people. If such a project was under the umbrella of a stable open source player like the Apache Foundation, then that would also help overcome the fear that if one adopts a cool ODBMS that the vendor will be bought up or go out of business six months later.
So my point is that, even though I suspect a survey of programmers would turn up a high percentage of people who would *love* to try out an ODBMS, the opportunity simply is not there when doing work for hire--the people who pay the bills feel safest with RDBMS.
Dan
Consider eliminating the OR mapping
Instead of doing the OR mapping how about using an object database.