SQL3's Object Extensions

The SQL3 project aims to add object-oriented (OO) extensions to the SQL-92 syntax, making SQL object-friendly and enabling relational databases to handle more complex data types. But there have been some serious and fundamental problems with the SQL3 effort.

First, the committee began with a discouraging word in 1993, when Bjarne Stroustrup, the inventor of C++, said that he knew of four ways to store persistent objects and that they were all b ad. He then stated that he believed the OO paradigm was goo d for programming but bad for data.

Second, the rules of the Standards committee require SQL3 to be upward-compatible with the current SQL-92 standard. Consequently, any ODBMS features must be cast into a syntax that might not be good for OO constructs. The solution is an informal agreement between the ODMG and NCITS H2 to make the queries in SQL3 and OQL identical, or at least to overlap each other on most major points. But the schema declaration languages are still quite different.

Another area of concern is the interface. The 3GL host languages for which an interface to SQL-92 is defined (FORTRAN, Ada, C, M, COBOL, Pascal, and PL/I) have no basic disagreements about how to handle the scalar data types used in SQL. But C++, Smalltalk, Java, Eiffel, and several minor OO languages all disagree on OO fundamentals, such as inheritance, polymorphism, and encapsulation. OO vendors solve this problem with object brokers that automatically convert one object model to another one. Thus, the object database matches its host program.

There are political considerations. The object effort in SQL3 began with three sides, represented by Hewlett-Packard, Oracle, and IBM -- three RDBMS vendors. Each had a different object model and different features to add to SQL3. Having little experience with ODBMS, the committee approved proposals from all three companies. The internal contradictions and inconsistencies in the SQL3 draft document became so great that the ANSI X3H7 Object Standards committee sent a memorandum of concern to ANSI X3H2 on reviewing the document. Most of the current effort in SQL3 has been the cleanup of these problems.

Finally, in interviews we conducted, there was little endorsement of or enthusiasm for SQL3 from the ODBMS vendors. If they have to do it, they will. SQL3 will not be an approved de jure standard before 1999. By that time, the market will have established de facto standards. The most likely candidates for an object-database language are OQL and Java. OQL i s already defined and has wide vendor support. Java is becoming the de facto language of the Internet, where the capability of ODBMS products to handle nontraditional data will shine.