|
Porting Difficulties
Saving objects to an OODB is vastly different from saving objects to most relational databases. Consequently, it is a chore to move your RDB-based system to an OODB and once you commit your design and development to an OODB, you may find it difficult to move back to an RDB.
For many projects, it is much safer to migrate from a relational database to an object relational database. Some vendors such as Oracle have made this migration a natural one by simply adding object relational features to their core product. As a result, your legacy RDB can often be extended to incorporate object relational functionality and ported in a piecewise fashion.
Multiple Skill Requirements
As with RDBs, each OODB tends to have its own proprietary quirks and extensions. Consequently, finding people with skills that are specific to a given OODB will be more challenging than finding people with mainstream RDB skills for a given database (i.e., DB2, Oracle, Microsoft SQL Server, etc.). Furthermore, finding individuals with proven, deep experience in OODB administration will be challenging. Granted, many OODB users feel that OODBs require less administration in the early stages, but like most growing systems OODBs still require tuning in preparation for deployment. Switching from a relational to an OO database paradigm also will require some training and mentoring because issues such as performance, locks, and joins often require different approaches.
Complex Queries
Query support varies quite a bit among the various OODBs. Your application will not always be able to retrieve an object by its Object ID. Rather, there will be times when you need to search by ranges, patterns, and fuzzy criteria spanning objects that do not have obvious relationships. Ad hoc query support seems to be an area where OODBs find it difficult to compete in both performance and features. It is likely that this functionality will continue to mature, and many applications do have well-defined retrieval requirements that will not suffer due to any loss of ad hoc query functionality.
A Fascinating Tool
OODBs are a fascinating tool, and a real delight for application developers to work with. They introduce new abilities that many of us have been longing for during our battles with relational databases. However, each OODB product seems to bring unique strengths and weaknesses. Thorough evaluation of the products against your project's needs is critical—a newer product must have very compelling advantages in order to displace a working, reliable solution. You may find that OODBs have sufficient benefits to justify their evaluation for your project. A number of successful projects utilized OODBs (see Objectivity and GemStone links in Resources column), and in fact many developers feel that a relational persistence solution could not have met their performance and design requirements.
Steve Franklin handles the architecture and project engineering responsibilities at a major software firm dealing with J2EE, client/server, command and control, and other distributed architectures. Steve Franklin's primary "off-hours" hobby can be found at Lookoff.com, a repository for Internet and research resources. He can be reached at steve@lookoff.com.
|
Performance Perks
Introduction 
Performance Perks 
