Recently a team of our object database experts - Adrian Marriott and Luis Ramos - attended the 2009 International Conference on Object Databases. Not only did they present on design patterns and discuss the resurgence of object oriented databases, but Adrian won an award (and a netbook!).
Adrian Marriott was the first place winner of the award for best Common Persistent Model Patterns for Performance and/or Scalability Optimization. He beat out 25 other compelling patterns with his Query Visitor pattern which allows one "to define new result set formats without changing the underlying persistent object model."
Roberto V. Zicari, Editor of ODBMS.ORG, said of Adrian’s pattern...
"It is common practice that some database designers treat an Object Database (ODB) like a Relational Database (RDB). That is they are very query intensive rather than model intensive in their design. Some designers start with a “relational” model, and then adjust it to a model that is more "ODB-oriented", or closer to their problem domain, in order to get better results. This task is difficult. Marriott`s pattern, Query Visitor, can speed up the database development process by providing a tested, proven development paradigm."
Luis Ramos contributed to the lively discussion in one of the more intriguing panel discussions at the conference: A New Renaissance for ODBMSs? As part of our post-ICOODB2009 coverage, I asked Dr. Ramos to share some thoughts about object databases and their use.
Me: What are some use cases that benefit from an Object Oriented Database?
Luis Ramos: There's three main uses cases: complex (multi-dimensional) data, transactional caching, cloud-databases—and given today’s SaaS-world, you can see why ODBMSs are becoming more and more relevant.
By complex, multi-dimensional data, I mean data that is hard to render into rows and columns. For an easy example of non-complex information consider the current roster for the Boston Red Sox Baseball team; the roster lists each player and their name, number, position and statistics–it looks like a rectangle with two dimensions. This formulation makes it easy for me to ask the question – what is the current batting average of the 1st baseman for the Red Sox?
But consider a slightly different question – how are individuals in a family tree related? Consider Barack Obama’s family tree. If you visualize the data, it is not a matrix at all. It looks more like a tree of nodes. This would be very natural to store as objects with links to other objects. Consider asking a question like, is George W. Bush related to Barack Obama? Answering this question is quite easy in an object database. You simply follow pointers from the node representing Barack Obama and see if you can reach George W. Bush (and apparently they’re 11th cousins). Following pointers or de-referencing references is certainly a lot more efficient than doing an arbitrary number of joins.
On the transactional caching use case. Our clients have selected object databases over other data caching technologies such as Memcache and Tangosol for a these important reasons: transactional access, durability, and automatic cache replacement. With object databases, there’s transactional access to the cache thereby preserving the data integrity of the cache – you don’t find this in many caching solutions. Also, the cache is durable. If the application is terminated intentionally or otherwise, recreating the cache is fast and efficient because it is being populated from an object database. In this case, there is no overhead for running SQL queries to find to the objects to bring into the cache and no overhead to transform between relational data and objects. Third, ObjectStore automatically manages the cache if the amount of data being accessed in the cache exceeds the amount of memory.
On cloud-databases, object-oriented databases are a more natural fit for persisting cloud data, which is inherently tuple-based, for a number of reasons. First, storing tuple-based data, whose values are arbitrary (strings, integers, double, boolean, etc) and that are automatically indexed could be challenging to do in a relational database. This type of problem is reminiscent of the issues related to formulating a relational model to store an object model that has an inheritance hierarchy. Second, scaling a relational database is not easy. The usual practice to scale a relational database in order to support more load is to use more powerful hardware. In an object-oriented database such as ObjectStore, it is easier and simpler. Since the queries are performed at the client (the cloud node or service), scaling the database can be accomplished by simply launching more services.
Stay tuned, the next post will cover additional Dr. Ramos’ comments about RDBMS to ODBMS, the market and where to get more information.
View all posts from Conrad Chuang on the Progress blog. Connect with us about all things application development and deployment, data integration and digital business.
Copyright © 2018 Progress Software Corporation and/or its subsidiaries or affiliates.
All Rights Reserved.
Progress, Telerik, and certain product names used herein are trademarks or registered trademarks of Progress Software Corporation and/or one of its subsidiaries or affiliates in the U.S. and/or other countries. See Trademarks for appropriate markings.