I have been asked to write a few words on the benefits of the object database model as compared to the relational...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
database model. Frankly, I hesitate to frame the discussion that way.
The reason for my hesitation is that I do not necessarily see object database (ODBMS) and relational database (RDBMS) products as competitive. Rather, I see them as complementary choices that, at times, can co-exist quite well in an enterprise architecture. Often, this is with multi-tier architectures. Two examples of how they can co-exist:
- Web-based catalogs where content is drawn from multiple, existing sources to "publish" the catalog in the middle tier. The ODBMS manages access to the catalog. The RDBMSs or other storage mechanisms manage the existing sources. Often, the middle-tier catalog is something new that has not existed before in the enterprise.
- Trading or auction systems that keep only the current items being traded or auctioned in the middle tier. The ODBMS manages the active trading or auction data. The RDBMS serves as the backend database or database of record which receives the necessary historical data from the ODBMS. Often, the middle-tier trading or auction systems are new or are replacing older, non-DBMS technology.
So, when should you consider using an ODBMS? For years, I have been telling my clients that they should be considering the use of an ODBMS only when they have a business need for high performance on complex data. Let me explain this further. If you
- are using an object programming language such as Java or C++;
- have, for perfectly valid design reasons, chosen to use advanced data structures afforded by the object-programming language; and
- need the highest performance possible,
then you should be considering an ODBMS product.
There are design problems that often are best solved using data structures such as lists, vectors, hash tables, queues, stacks, etc. that are available or can be constructed in object programming languages. Sometimes, it is necessary to make these data structures persistent. With an ODBMS product, you can store any conceivable data structure directly with no conversion whatsoever. (If you think about it for a moment, you can see that this is a mighty significant statement.)
Performance is also enhanced because there is no conversion or mapping between the object programming data structures and the ODBMS. Mapping between object-programming data structures and an RDBMS reduces performance. The more complex the data structures, the greater the reduction in performance. (More on mapping can be found here.)
Being able to store complex object programming data structures directly also saves on development costs because you write less code with an ODBMS as compared to an RDBMS. The reason you write less code is because you have only one data model to develop and maintain. Also, you do not need to write any mapping or conversion code that would be needed if you used a different data model in an RDBMS than the one afforded by the object programming language.
This tight coupling between object programming languages and ODBMSs is one reason you are starting to see more and more ODBMSs being used in embedded systems, but I digress...
So, going back to the two examples, both have data structures that exist only in the middle tier managed by the ODBMS. These same data structures are not needed in the co-existing RDBMS. In the first example, the assemblage of data from existing sources is only needed in the middle-tier catalog. In the second example, there are data structures needed for trading and auctions that are not needed for the backend database or database of record.
When you are developing an architecture, you should not assume that all your database needs must be met by one type of DBMS product. Another way to look at this is to use an analogy. Do you always use the same tool for different uses? A hammer is a hard way to drive in a screw! Or, for that matter, try pounding in a nail with a screwdriver.
We should look at all these database products based on architectural needs and pick the best tool for each job. This is why it makes sense to consider how RDBMSs and ODBMSs can be used together in a multi-tier architecture.
For more examples of multi-tier architectures, see this site.
About the author
Doug Barry is the founder of the consultancy Barry & Associates, Inc., Executive Director of the Object Data Management Group (ODMG), and the author of numerous books, including The Object Database Handbook.
For More Information
- What do you think about this column? E-mail the Editor at email@example.com with your feedback.
- The Best Web Links on the relational model
- Post your technical database questions--or help out your peers by answering them--in our live discussion forums.
- Ask the Experts! Our database design, SQL, Oracle, DB2, SQL Server, metadata, and data warehousing gurus will answer your toughest questions.