Why Use SQL Instead of an OODBMS?

On pages 82 and 83 in Understanding SQL and Java Together, Jim Melton and Andrew Eisenberg posed this question. Below, in italics, you can find their discussion of this question. Following each of their paragraphs, I have provided a response. You will see that some criticisms of Object DBMSs actually apply to Relational DBMSs as well. Also, you will see that some of the criticisms are based on out-dated information about ODBMSs.

Another alternative, endorsed by the Object Database (sic?) Management Group, is to manage your data through an object-oriented database management system (OODBMS). A number of such products are available, and many of them have Java interfaces. This option may be attractive under certain circumstances, principally because an OODBMS could have semantics that are close to those of Java, making it relative easy to store, retrieve, and manage objects instead of rows of data. However, although the market for OODBMSs is growing (even growing rapidly, according to some sources), there are several problems with this choice.

It is true that not all Object DBMSs (ODBMSs) support Java. I disagree, however, with the implication that ODBMSs that support Java might not have semantics close to those of Java. Object DBMSs that support Java definitely have semantics that are close to Java -- the data manipulation language for ODBMSs using Java is Java itself! Similarly, Object DBMSs that support C++ have semantics that are  the same as C++. This is the nature of transparent persistence. By the way, since object programming languages such as Java and C++ share much in their object models, most ODBMSs also allow simultaneous access using Java and C++. When using C++, the ODBMS has the semantics of C++. That is transparent persistence.

The first problem is that, in spite of the existence of a nominal standard for OODBMSs, the reality is that the products available today implement very little of that standard, and no two products implement the same bits. Although this criticism can be leveled at many different standards (including SQL's!), it is especially relevant for OODBMSs because their internal models tend to be widely divergent and the lack of a common language among multiple products makes it very difficult to overlook those model differences.

First, as mentioned above, this criticism can be leveled at both RDBMS and ODBMS products. Anyone who has moved a significant application from one Relational DBMS (RDBMS) to another will tell you that the uneven implementation of SQL and proprietary SQL extensions among RDBMS products makes this a significant effort. 

Second, I am puzzled by the comment that the "internal models tend to be widely divergent and the lack of a common language among products." That may have been true in the early 1990s when ODBMS products were first introduced. Today, there is a high degree of commonality among ODBMS products that use Java through support of Java Data Objects (JDO). This is also true of many object-relational mapping products. See Java Data Objects.

Third, not everyone has implemented all specifications or all of a particular specification, probably giving rise to the comment that "no two products implement the same bits." Here are some clarifications concerning commonality among ODBMS products:

• All ODBMS products provide processing of class definitions for defining a database. This is usually done by using Java or C++ class definitions for the basic structure along with additional meta information. It is true, however,  that there was generally little interest in the ODMG Object Definition Language (ODL) among vendors.
• Nearly all ODBMS products use an SQL-92-based query language. The Object Query Language (OQL) was also not widely adopted because most vendors already had a SQL-like query language (OQL is also based on SQL-92). So SQL-92 for queries is definitely "intergalactic dataspeak" since both RDBMSs and ODBMSs use it. (See the reference to intergalactic dataspeak further down.)
• Nearly all the ODBMS products implement either the JDO Java,  ODMG C++, or ODMG Java Binding. Some vendors chose to implement only one binding. Some vendors implemented all three. It all depends on what they saw as their market.

I would say the track record of ODBMSs is roughly no better or no worse than RDBMSs in fully implementing their respective standards.

This situation leads to a second problem: the ability to apply personnel trained on one OODBMS to work using another. Without a common model or a common language, knowledge gained from using one system cannot readily be applied to a different system.

The primary training that you need to work with ODBMSs is the object programming language you are using with the ODBMS. That training, of course, will transfer to another ODBMS.

For example, let's look at Java with respect to ODBMSs. Basically, for those ODBMSs that support Java, all data manipulation is done in standard Java. ODBMSs add only a few additional commands to Java that involve opening databases, starting transactions, issuing queries, ending transactions, and closing databases. Yes, that's only a handful of commands beyond Java. Well, to move to another ODBMS, one's knowledge of Java does not go away. It certainly transfers.

So, one could make the argument that more knowledge gained from using one ODBMS can be applied to another ODBMS simply because of transparent persistence.

In contrast, SQL (the so-called intergalactic dataspeak) allows implementations of relational database management systems to shield (largely, if incompletely) application programmers from their internal models and to provide an interface to the data they manage that is significantly like the interface provided by other SQL products. In this way, training on one product can be meaningful when working with a different product.

See the prior response. Also, much like SQL, the ODMG Binding and Java Data Objects (JDO) shield programmers from internal models. All of these specifications, whether it be SQL-92, SQLJ, JDBC, SQL:1999, ODMG 3.0, or JDO, are simply interfaces. They can all be used on RDBMSs as well as ODBMSs. See the Summary Comparison of DBMS Standards.

A third problem is perhaps more subtle. OODBMSs excel at managing objects, especially in environment where the operations to be performed on those objects are reasonably well known when the database is designed. They rarely perform well when called upon to deal with ad hoc query environments or applications requiring significant use of traditional data such as numbers and character strings. SQL is well designed to deal with that traditional data, and virtually all SQL products today are quite efficient when dealing with unpredictable -- and unpredicted -- queries and combinations of data.

No argument here. SQL products are designed to deal with traditional data. ODBMSs, on the other hand, are good when you have a business need for high performance on complex data. See when an ODBMS should be used.

There is another advantage to using transparent persistence provided by ODBMSs: reduced development costs because less code needs to be written. ODBMS and object-relational mapping products both use transparent persistence. You end up writing a lot less code with transparent persistence. For an example that shows transparent persistent access to an RDBMS requiring only 25 percent of the code needed compared to using JDBC, see transparent persistence vs. JDBC call-level interface. I think it would be fair to extrapolate these results to embedded SQL. In fact, I have received plenty of anecdotal evidence from my clients that indicates the code required for a transparent persistent interface ranges from 25 to 40 percent of the code needed for either JDBC, SQLJ, or embedded SQL. That can obviously have a big impact on development costs.

The last situation brings us to a final alternative: combining an SQL product for managing traditional data and an OODBMS for managing complex, object-oriented data. Several variations on this theme come to mind, but two of them illustrate the possibilities. You could buy an SQL product and a separate OODBMS product and write your applications to use the first for traditional data the the other for objects, using a third product -- a transaction monitor -- to ensure that transactional semantics are applied to updates that invoke both products. Alternatively, you could acquire a product with thorough SQL support built into it that has also integrated support for object management, either through the use of specialized storage managers or through built-in object facilities. The first choice requires that your application manage the relationship between traditional data and objects, but probably allows greater flexibility in choosing the products you acquire. The second option may limit your product choices somewhat, but all of the major SQL vendor are delivering products that support one (or sometimes both) of the variations we mentioned. Among products that are SQL-based and have integrated object support, the fastest growing approach to delivering that support is to integrate Java with the database engine in some fashion, which of course, is what this book is primarily about.

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 products based on application needs and pick the best tool for each job. An alternative to the last suggestion above is to consider how both RDBMSs and ODBMS can be used together in a multi-tier architecture. It makes sense for RDBMSs to be the "database of record" in many organizations. It also makes sense to use an ODBMS to service the needs of Internet access. See the example middle-tier architecture. Several ODBMS products have features that allow them to work well with Java application servers (a third product as mentioned above) and RDBMSs. You don't have to write the Java application server/RDBMS/ODBMS integration yourself as is implied above. More on enterprise architectures using Java application servers.

? The name of the organization is Object Data Management Group. The name was changed in 1999 to better reflect its mission to specify and promote transparent persistence for both object databases and object-relational mapping products.

Context for Why Use SQL Instead of an OODBMS?

Home » Articles » Object Database Articles » ODBMS Myths » Object Database Problems? » Why Use SQL Instead of an OODBMS?