Object vs. Relational
There has always been friction between the object world and the relational database world. This friction manifests itself in code as the Object/Relational mapping layer (O/R layer). This layer allows programmers to read and write data from a relational database in an 'objective' manner. The first and primary value of an object database is the removal of this layer from the program. Because the database can store object data directly there is no requirement for a layer to translate the object world into the relational world.
The second advantage of an object database is that the variable types in the object database are the same as in the host programming language. This includes complex data types such as structures and classes. Large and complex object and data structures can be stored and retrieved from the database with relative ease in comparison to the same set of operations applied to an SQL database.
The third advantage is the absence of a new syntax for storing and retrieving data. Using an SQL database means learning SQL syntax and optionally a stored procedure syntax. Object databases have storage and retrieval methods available within the host language context. Therefore, comparatively little extra knowledge is required. Certainly nothing along the lines of learning a new language.
One of the downsides of an object database is its direct linkage to the object format and data types of the host language. This causes problems when other languages attempt to query data from the store. An ideal use for an ODBMS, even with this caveat, is as an application-tier temporary object store.
A second alternative to the SQL database is the Native XML Database (NXD) which can store and query XML documents in their hierarchal form. This makes storing complex data forms much simpler than it would be in an SQL database. Some SQL databases have support for XML as a native datatype but it is not directly integrated with the SQL implementation and the performance issues can be prohibitive.
So there is a value in the alternatives to the SQL model, but that value needs to be weighed against the cost.
A Little Respect for SQL?
Whether it's elaborate O/R mapping layers, OODBMS or XML databases, engineers are looking to other technologies to solve problems that have solutions already built into their SQL DBMS.
Many in the Java community use SQL complexity as support for an argument to move on to other technologies. For example:
- At O'Reilly OnJava, Dion Almaer writes: "This is a new world, where developers can focus on their business needs and work with objects without having to be SQL gurus."
- At The Server Side, Basil Tchurilov writes: "This method is labor intensive, error prone, requires SQL expertise, and does not have caching capability. So it will be much more appropriate to use ODBMS as storage for Java components."
SQL isn't difficult. You don't have to become a guru to use it. You just have to take some time. Besides, if you are writing and data-driven application and using a SQL database then your application will be using SQL even if you don't know about it and could be suffering from performance problems simply because of inefficient SQL.
Author and DevX reader Norman Richards criticized my last commentary in his blog this way:
"The conclusion: after all these years of usage, relational databases have completely failed to provide a reasonable level of standardization or interoperability. What is worse is that most programmers I meet have never worked with better technologies and don't seem to realize how bad off the situation is."
I agree that there are vendor incompatibilities that create difficulty, but the situation is no better in the OODBMS or XML database world. The value in SQL is that there are standards and those standards are dedicated to the support of the robust and solid database platforms upon which we can build applications.
SQL databases aren't glamorous. They aren't all that new, though they aren't all that old. And the emphasis on reliability, data integrity, and durability isn't very sexy. But these systems work, and they work very well.
It's time to stand up and give deserved credit to the database engines that have been at the heart of our data-driven applications for years. It's also time to use them properly, which means using the referential integrity features, using the stored procedures, and writing quality SQL that makes efficient use of the database.
|The author would like to thank Darryl Hasieber, a U.K.-based MCSD and MCDBA working as a software developer and database design consultant, for his contribution to this article.