The Legend of Data Persistence - Part 2
3. ODBMS Versus RDBMS
Having looked at the basic features and types of ODBMS, let’s examine its advantages and disadvantages in comparison to RDBMS
a. Advantages
- Rich domain model: since ODBMS can store objects at any level of granularity and has built-in suport for identity, association, and inheritance, OO developers can model their domain classes as richly and expressively as they want without being constraint as with the relational world
- Maintainability: since the application object model and database object model are closely related to each other (in non-native object databases) or even are the exact same model (in native object databases), it takes less effort to maintain these models as the application evolves
- Development effort: the ability of developers to implement rich domain domain with the least maintainance effort would result in a significant reduction in development time and cost.
- Performance: ODBMS is supposed to perform much better than its RDBMS counterpart, regardless of whether O-R/M tools are used or not, in systems with highly complex object model, since no complex queries (e.g. joins) and mapping are required
b. Disadvantages
- Portability: data in RDBMS can be shared by applications written in any paradigm and platform while ODBMS is tied to the OO world. The situation is even worse for native object databases since the data cannot be used by multiple applications with different domain classes, even if they share the same data. As a matter of fact, the clear separation between the relational model and object model further assists portability of RDBMS since these two can evolve independent of each other
- Legacy applications: there are so many applications built with a RDBMS back-end that it is impractical to migrate all these data into ODBMS. In addition, not only the data has to be migrated, the applications which consume the data will also need to be modified to make use of a OO data access mechanism
- Maturity: the ODBMS industry are new (emerged since the 90’s) and thus is far from close to RDBMS world (emerged since the 70’s) in terms of available system vendors (including the compatibility among database systems from different vendors) and tool supports (such as reporting, OLAP, data transformation, and clustering services etc.)
With the above analysis, ODBMS is not so much of a silver-bullet that some people hope for and thus the decision whether to use ODBMS in a project or not must be considered very carefully. However, once we have done the homework and decided that object databases can be used for our applications, then we can sit down and enjoy the huge productivity gain which cannot be achieved if we stick with relational databases. In the final part of this article, we will look at the DB4O object database system. Stay tuned!
[...] Part 1, I will discuss about the object-relational (O-R) impedance mismatch, its consequences, and ORM [...]
[...] Part 1 and Part 2 of the article entitled The Legend of Data Persistence, I have introduced you to the O-R impedance [...]
Your entries about OODB are very nice. I am a novice of OODB. And they are useful to me. Thank you.
@New Age: You are welcome! I’m glad it’s helpful to you.
Hi. I’m wondering what happen when the source code of the application is lost and you need to move data to a new application.
@tibbs: I’m not exactly sure what you mean. If you’re talking about a “new application” here then what is the deal with the old app (whose source code is lost)?