|
Performance Perks
Depending on the product and implementation you pursue, OODBs can bring significant performance to the right type of application. If your application uses an RDB and you must reconstruct an object from data in the database, you frequently have to perform multiple queries. Each of these queries incurs overhead and, without careful planning of indices, can result in serious performance penalties. An OODB reduces this problem significantly, provided that you know the object identifier or OID—the database retrieves the object in its entirety or as a lazy fetch, a query technique by which your code loads portions as needed.
A number of OODB implementations also employ client-side caching in addition to server-side caching. Although this has its disadvantages, it certainly can improve application performance. You often will see "warm" and "cold" database benchmarks, where a warm benchmark implies one or more reruns of a test to evaluate caching and buffering advantages. OODBs often excel at warm benchmarks because of their client-side caching facilities.
OODB Weaknesses
Object-oriented databases have weaknesses that you must consider as well. One of the most obvious and significant drawbacks is the risk involved in an RDB-to-OODB migration. Relational databases have their own cons but they are proven and successfully used on data-driven systems. The architecture/design patterns for integrating RDBs into your system are well defined and demonstrated.
Tight Application Coupling
In many OODB implementations, the OODB is tightly coupled to the application. This simplifies both the design and code, but the data abstraction layer has some value also. By removing it, you lose a layer of insulation from the database. This can make it more difficult to migrate to a competing product without significant changes and re-tests. You could always implement a data abstraction layer around the OODB implementation. Although you would lose some of the OODB's benefits by doing this, development of this layer for an OODB certainly would be cheaper than creating an RDB equivalent.
Performance Flaws
I have already discussed an OODB's strength at retrieving entire objects efficiently. OODBs typically are weaker for ad hoc queries against the database. Loose navigation through data can be challenging, too, and OODB query optimization and functionality often lags behind major relational database products.
Some OODB implementations do not provide sufficiently granular locking. Consequently, your code could lock huge groups of objects if you are not careful. Whereas most RDBs implement row-level locking, some OODBs still implement page locking. Furthermore, locks can span relationships within an object, potentially allowing one action to lock a significant amount of data.
Limited Platform Support
Even when an OODB is implemented in Java, you should still look for a guarantee of support on a variety of platforms. Although Java is portable, complex Java software can have quirks and nuances in a given environment, to which only the vendor can help you migrate. Some OODB vendors are unable to devote adequate resources to a broad support base across multiple platforms because they have smaller budgets than major RDB vendors. To gauge platform support, find out what the vendor provides and check newsgroups (e.g., comp.databases.object and comp.object) to monitor the frequency of discussions for a given platform and product combination.
|
Introduction
Introduction 
Porting Difficulties 
