The latest in a long line of supposed "us vs. them" controversies is the great ODMG/SQL3 debate. The "us" here is the part of the DBMS industry embracing the object model and object programming languages, while the "them" is the part of the DBMS industry needing to extend the relational model with some object characteristics. The choice between ODMG and SQL3 is not so much about finding the one "right" answer as it is assessing your application requirements correctly--in short, asking the right questions.
In this column I will give you an idea of what these questions are. But, before we get to that, I have a few late-breaking news items to pass along.
News flash: The ODMG is no longer the Object Database Management Group. The ODMG has formally changed Chapter 1 of the ODMG Standard to reflect its broadened charter, which now includes any storage mechanism that uses the ODMG specification. (Previously, the ODMG standard referred exclusively to object database management systems.) Chapter 1 now states that the standard "applies to two kinds of products: object database management systems (ODBMSs) that store objects directly and object-to-database mappings (ODMs) that convert and store objects in a relational or other database system representation." By expanding the charter, we intend to make clear that the ease of use and productivity benefits of the ODMG object-storage specification can be achieved on a wide range of database architectures. Moreover, we are inviting active participation by the many companies that are using the ODMG bindings, particularly in the exploding Java segment.
Because we have broadened our charter to include any storage mechanism that implements the ODMG specification, we have also renamed our consortium, changing the name from the Object Database Management Group to the Object Data Management Group. Small change in name--big change in meaning!
In my previous column, I told you that the ODMG binding for Java was the only standard specification that lets you store objects directly without writing any mapping code. As of press time, eight vendors are offering support for the ODMG binding for Java: Sun Microsystems, Computer Associates, Object Design, Versant, POET, Objectivity, Ardent Software, and Objectmatter. I expect there to be more by the time you read this.
My final news item is to note that Chapter 7 of the ODMG standard, the ODMG binding for Java, has been updated to maintain compatibility with Sun's Java Development Kit (JDK) Version 1.2. The most important factor in this update is support for the expanded JDK 1.2 collection classes, which are especially important to database applications because they're used to model relationships between objects (one to one, one to many, and many to many). The update to Chapter 7 ensures that these JDK 1.2 collections will be supported "out of the box" by databases that comply to the ODMG Binding for Java. It also means that CASE tools and forms generators will be able to work with persistent Java objects stored in ODMG-compliant databases. The updated Chapter 7 for JDK 1.2 is available in the latest reprint of the standard.
Down to business. When people ask me to explain the differences between ODMG and SQL3 in the context of object storage in databases, I am often reminded of the old saying "If you want better answers, start by asking better questions." That's especially true of this topic, which is consistently described in "us vs. them" terms. I will argue that the whole issue of whether to use ODMG or SQL3 boils down to two basic questions:
•What are you trying to do? Are you developing a new application using an object programming language, or are you extending an existing relational application?
•How much do you care about productivity when working with objects?
Let's consider the first question--what are you trying to do? If you are merely extending an existing relational application to give it some object capabilities, then SQL3 is the simplest approach. However, if you are building a new application, you will likely choose to use an object programming language such as Java or C++. Recall that the ODMG specification is a set of extensions to object programming languages that gives them full data storage capability. Therefore, when you are writing an application in Java using an ODMG Java-compliant database and you need to make an object persistent, you simply store the object directly in the database. Transient and persistent objects are identical to the Java developer and appear together within the same environment.
Using SQL3 on objects, however, there is a fundamental misalignment between the object models of object programming languages and what I'll call SQL3's "object-extended" relational model, so there's no such thing as storing an object directly in the database. In object storage parlance, we refer to this problem as an impedance mismatch: Because the data models are different, you have to write translation code to map your application's object model into the SQL3 object-extended model for storage. If your data model is at all complex, this entails a substantial development effort that contributes absolutely nothing to the feature set of your application. Should you be tempted to go this route anyway, you should also be forewarned that, according to some estimates, the mapping code could end up representing as much as 30 percent of your total application code.
But wait--I'm not done. Not only do you have the initial work of writing the mapping code, but as your application's data model evolves, you will have to go back and spend time rewriting it code to reflect those changes, so you have a real maintenance headache. That flies directly in the face of one of the great benefits of object programming: the ability to rework objects without adversely breaking other pieces of code.
Now on to my second question: How concerned are you with productivity? The mapping code you'll have to write to use a SQL3-compliant DBMS with an object programming language is going add to your time to deliver your application. For most of us, that's a big deal--especially if it requires writing 30 percent more code. Besides, do you have the development dollars to spend teaching your Java developers trying to become database experts?
Here the beauty of the ODMG specification becomes apparent. Whether you choose to go the full-object DBMS route or you choose an ODM, you get a much higher level of productivity because your application only needs to know about the objects it manipulates and nothing about how to access or store the objects. You also get the power of portability. Once you have implemented an application using the ODMG binding, it is directly portable across a wide range of DBMSs. You can then select the one that best meets your technical and business requirements.
The thing to remember about SQL3 is that it was not designed to be compatible with object programming languages. Rather, the overriding consideration in the development of SQL3 was to retain complete compatibility with SQL-92 while offering object extensions. Because SQL-92 is based on a tabular view of data, retrofitting it with objects is a little like putting turbofans on a Volkswagen Beetle: It may be possible, but it won't win any design awards or give you the productivity that you're after. Moreover, because the SQL3 standard must handle objects in a management-by-exception fashion, the standard has swollen from 600 pages for SQL-92 to more than 1,100 pages for SQL3. Contrast this with the ODMG standard, which provides complete object-programming language bindings for Java, C++ and Smalltalk in 250 pages. Not only is SQL3 a bulky standard, it's difficult to use. A lot harder than SQL-92. If you don't believe me, see the article by Oracle's David Beech, Can SQL3 Be Simplified? (January 1997), that addresses these very concerns.
Regardless of these considerations, it remains a fact that the SQL3 object model does not match the Java or C++ object models. You've still got impedance mismatch and the attendant thrills and spills of mapping between your application's object model and the SQL3 object model. However, if you have a conventional relational application to which you would like to add limited support for objects, SQL3 is still the obvious choice.
You may be thinking, "ODMG. Java. Productivity. It's all very well and good, but I've got a shop full of SQL programmers and zillions of lines of SQL code. Once I've got this fire-breathing database application built, how am I going to do queries?"
There's good news here. The ODMG specification also includes an object query language (OQL) based on SQL-92. OQL differs from SQL3 in that it does not strive to maintain complete compatibility with SQL-92. Rather, it follows SQL-92 until the relational model interferes with the object model, at which point the object model takes over. Our goal was not to assert 100-percent compatibility with SQL-92, but rather to ensure that OQL would be highly familiar to SQL-92 programmers and, therefore, easy to pick up and use immediately. In fact, the ODMG collaborated with the SQL3 committee in an attempt to create a single query language, and changes were made to both standards to bring the two query languages together. Unfortunately, as SQL3 has moved through its adoption process, the two organizations fell short of their mutual goals and the two query languages remain different.
Let's look at an ODMG OQL query. Here is an example from the published ODMG standard (ODMG 2.0. Morgan Kaufmann, 1997):
select c.address from Persons p, p.children c where p.address.street="Main Street" and count(p.children) >= 2 and c.address.city != p.address.city
This query inspects all children of all "Persons," but restricts the result to the people living on Main Street and having at least two children. Moreover, it returns only those addresses of the children who do not live in the same city as their parents. It navigates from the Person class using the child reference to another instance of the Person class and then to the Address and City classes. It navigates the objects in the manner shown in Figure 1.
The other thing you need to know is that OQL is strictly a query language, where SQL3 is broader in scope, covering data definition and data manipulation in addition to queries. The ODMG standard also provides for data definition and data manipulation, but in a different way built on object standards. Data definition is provided using an object definition language that is a superset of the Object Management Group's interface definition language (IDL) for CORBA. And as we've already discussed, the ODMG specification uses object programming languages for data manipulation using tight language bindings. Therefore, manipulating a database object is no different from manipulating a nondatabase object when using an ODMG language binding.
The Final Question
Which should you choose? ODMG or SQL3? As I've shown you, the answer to the question depends on the answers to the questions we've discussed. First, what are you trying to do? Are you building an application in an object programming language such as Java or C++, or are you extending the life of an existing relational application by giving it some object capabilities? If you're doing object programming, you should seriously consider the benefits of the ODMG specification. If not, SQL3 may be satisfactory.
Second, how concerned are you with productivity? The impedance mismatch between object programming languages and SQL3 and resulting mapping code will result in a significant productivity penalty. The ODMG specification poses no such productivity problems. The more complex your data is, the more difficult it is to implement a satisfactory solution in a relational framework. You really need an object storage methodology like the ODMG.
For more information about the ODMG, visit its Web site at www.odmg.org.
Douglas Barry has worked in database technology for more than 20 years with an exclusive focus on the application of database technology for objects since 1987. He also serves as the executive director
of the ODMG. You can email him at dkbarry@odbmsfacts.com. His Web site is www.odbmsfacts.com.