SQL Object Integration

by Vickram H 2012-07-30 12:03:45

SQL Object Integration

The most significant unknown in the future evolution of SQL is how it will integrate with object-oriented technologies. The center of gravity of application development has clearly shifted to object-oriented techniques and tools. C++ and Java are growing in popularity, not only for client-side interaction, but for server-side business logic as well. The core row/column principles of the relational data model and SQL, however, are rooted in a much earlier COBOL era of records and fields, not objects and methods. The object database vendors solution to the relational/object mismatch has been the wholesale discarding of the relational model in favor of pure object database structures.

But the lack of standards, steep learning curve, lack of simple query facilities and other disadvantages have prevented pure object databases from having any significant market success to date. The relational database vendors have responded to the object database challenge by embracing object-oriented features, but the result has been a proliferation of non-standard, proprietary database features and SQL extensions.

It's clear that relational database technology and object technology must be more tightly integrated if relational databases are to remain an integral part of the next generation of applications. Several trends are visible today:

• Java-based interfaces to RDBMSs, such as JDBC and embedded SQL for Java, and perhaps additional interfaces more like those presented by the OODBMSs.

• Java as a standardized stored procedure language for implementing business logic within a RDBMS. Virtually all of the major DBMS vendors have announced plans to support Java as an alternative to their proprietary stored procedure languages.

• Abstract, complex data types that exhibit object-oriented capabilities such as encapsulation and inheritance. Beyond high-level agreement on the need to store "objects" within a row/column structure, the specifics (nested tables, arrays, complex columns) vary dramatically.

• Extensions to standard SQL constructs to deal with complex data structures, including the extensions in the object-oriented parts of the proposed SQL3 standard. The diversity in SQL extensions matches the diversity in the way objects are being integrated into the relational model.
• Message-oriented interfaces, including database triggers that produce messages external to the DBMS for integration with other applications.

Whether these extensions to SQL and the relational model can successfully integrate the worlds of RDBMS and objects remains to be seen. The object-oriented database vendors continue to maintain that object capabilities "bolted onto" an RDBMS can't provide the kind of transparent integration needed. The enterprise DBMS vendors have announced and added substantial object-relational capabilities, but it's hard to determine how many of them are actually being used.

In addition, new, Internet-driven standards (such as XML, the Extensible Markup Language) provide "quasi-database" capabilities by adding database like structure to document architecture. With all of these competing alternatives, the further integration of object technologies into the world of relational databases seems certain. The specific path that this evolution will take remains the largest unknown in the future of SQL.

You must LOGIN to add comments