 espite the advantages that object-oriented databases (OODBs) can offer over relational databases (RDBs), OODBs have not been able to shake the RDB stronghold on data-driven systems. They are a newer technology that has proven popular with many DB architects, yet application developers often opt for RDBs.
Don't overlook OODBs for your next database project. To choose the right one for you, evaluate your risk tolerance, technical requirements, performance needs, and overall technical solution. Under the right circumstance, an OODB can be an excellent tool. Under the wrong circumstance, it can force significant design rework—if not architecture rework—down the road. Learn the strengths and weaknesses of the OODB option.
OODB Strengths
Design Elegance
An OODB can simplify your system's persistency challenges. For dynamic systems, significant effort is often invested in the data access layer. An OODB does not eliminate the need for this effort, but in many cases it can make deciding how to save and retrieve information simpler.
In an object-oriented project, integration between the application logic and the archived data can be fairly transparent. The ability to keep the persistence and application logic in the same object-oriented paradigm simplifies modeling, design tool requirements, and visualization of the system architecture and design. Some OODBs even have small footprints that allow them to integrate with your application on an embedded system.
With some OODBs, you may be persisting not only data but also the entire object, including its implemented behavior. Also, some OODBs allow you to call the persisted object's methods on a remote database server, thereby giving you some advantages in scalability and distribution. In a relational database, by contrast, you'd need to implement stored procedures or COM objects to accomplish this, forcing some duplication of coding efforts or a more awkward architecture.
Reduced Development
Training and ramp-up can represent a significant cost to projects. Furthermore, tool requirements, peer reviews, build instructions, and test requirements can be complicated because of multiple tool, language, and environment support. An OODB can reduce the number of required languages in your architecture. The development team would no longer need to have skills in technologies such as JDBC, Pro*C/C++, and PL/SQL. Instead, developers are able to work with more commonly known concepts such as Java objects, iteration through collections, etc.
OODBs also can reduce development time by allowing developers to focus on object persistence, not the decomposition of objects to rows and parent/child relationships in one or more tables. In most cases, a developer simply saves an object to the database. Compare this single-step procedure with the challenges of saving a complex object to an RDB. Not only does the developer have to reduce the object to a series of records, but transaction management, error handling, and subsequent reconstruction also will be required when retrieving the object. Furthermore, object attributes must be ported to ANSI-compliant data types.
Some OODBs provide fairly seamless integration between the application and persistence code, which simplifies debugging and testing of the final product. Whereas some database architectures require libraries and a protocol between your application code and your data store, an OODB can skip this constraint and allow your debugger to monitor what happens as the data is being saved.
|
Porting Difficulties 
Performance Perks 
