What JDO allows is to mitigate this risk. If the project uses JDO with an underlying object database, the database can be replaced without changing the whole implementation. Just the database-specific (JDO implementation-specific) part would need to change.
So programmers can now use the same JDO programming paradigm for either relational or object databases, and choose the right underlying technology based on the robustness, performance, scalability features, not based on how big and reliable the company is.
Originally posted by Rama Raghavan:
ODBMS have been mentioned well before JDO..
Would one still choose an object database or will JDO drive Object Databases from concept to near death (ofcos there are some production impls) ?
[ June 19, 2003: Message edited by: Rama Raghavan ]
Object databases have existed for over 20 years. Which makes some relational vendors sound silly when they are still saying ODBMS is immature, which I have personally heard them saying since 1987. (Many were saying relational was still immature back then!)
There are a couple of features that distinguish object databases relative to relational databases. One feature was the notion of using the application's object model as the basis for the data model used by the database. Now with JDO, we have a standard interface defined that allows object models to be placed in relational databases. There are roughly 15 relatioanl JDO implementations now. So this object database characteristic of using an object model as the basis for your application can be done with a relational database. So from that perspective, one of the main benefits of an object database is now provided for relational databases.
Another characteristic of object databases that distinguished them from relational databases is the techniques they used at a physical level in the database to efficiently represent references and collections. This direct physical level support at the storage level allowed applications using an object database where they primarily traversed known relationships in the data, represented by the object model and directly mapped at a physical level in storage, to attain performance that was orders of magnitude faster than relational databases. So you would see object databases applied in application domains that had fairly complex data models with lots of interrelationships. The larger the datasets and the higher the degree of interrelationships, the larger the performance improvement you would get from an object database versus a relational database.
The main reason object databases have not gotten wide market adoption yet is that there has not been a standard interface supported by all the object database vendors. They tried to establish a standard with ODMG, but the object databases vendors on average did not fully commit to the standard. So ODMG became a paper standard, but not a real standard.
With JDO defined in a manner that it can be mapped to object, relational, and a variety of datastores, and because there has been a significant level of adoption by OR mapping vendors, and the fact that JDO was standardized through the JCP, JDO is quickly becoming THE standard for object-level persistence. It is primarily supported on relational databases to date. Some object database support is available now, and the others are working on completing their JDO implementations, which should all be out by year end. Unless relational database vendor-specific optimizations are used in the relational JDO implementations, the highly efficient object database representations for references and collections will allow object databases to attain much better performance for the more complex data models. So object databases will enjoy a significant performance advantage over relational for these more complex data models. But Oracle, for example, has features that could be used that are quite similar to the features in an object database. Yet none of the relational JDO implementations are using these features yet.
Oracle is campaigning against JDO right now. And IBM is not adopting it either. My belief is that they know and understand this inherent performance advantage that object databases have for certain data models. They also understand that with JDO your application becomes completely independent of the underlying database. Since they are in a market dominant position, they are against JDO, for fear it will erode their market share. A wiser choice for Oracle would be to leverage some of the unique features in their product that would yield a high performance JDO implementation. But this will take some time and work, so right now they are trying to convince the market not to use JDO, but to use their proprietary TopLink product.
One issue is that many people are not aware of these fundamental performance differences. The database community has made it near impossible to publish performance studies by establishing licensing agreements that put you on the road to a lawsuit against you if you publish any performance results. But I do believe word will get out about the performance differences. And with the portability provided by JDO letting you so easily switch from one database architecture to another, I actually think that the object database market will grow as these performance advantages become better understood. Yet many people have corporate edicts that demand they use one particular database, so there will be some resistance to change, etc.
I should also mention that my company has developed a JDO implementation of the OO7 benchmark, which was used in the early 1990s to compare object database performance. So I know first hand the kind of performance differences that exist. But legally, I cannot publish the results. All I can do is license my OO7 implementation to people that can run the benchmark and observe the differences for themselves.
Originally posted by David Jordan:
Yet many people have corporate edicts that demand they use one particular database, so there will be some resistance to change, etc.
Let's not forget that the enterprises have LOTS of legacy stuff running against ODBC/JDBC/DBI and so on. Somehow I doubt there will be any significant movement towards object databases until the enterprise can use their existing tools/applications with the newly introduced object database.
But one must understand their application requirements and know whether database traversals are going to be based on known static relationships among entities or need to be expressed in a more dynamic fashion using SQL's join operators.