Object Oriented Database Learning Center

Objectivity Home - Government - Objectivity/DB - Webinars - Download Software

Table of contents:

Building High-perfomance Object Oriented Databases

The Problem: The largest data management system vendors provide a "one size fits all" solution to database management based on relational database theory. Over the last 15 years, there have been many arguments about the advantages and disadvantages of the relational model and these arguments will continue for many more years. The biggest proponents of the relational model say vehemently that the relational model has only been partially implemented by the largest vendors. Criticism of "relational" databases gets confused with criticism of the relational model.

This paper will not attempt to argue the merits of the relational model, except in how it has been generally implemented. “Relational” databases became very popular in the 1970’s, not just because they were based on the relational model, but also because they supported the SQL interface.

Although SQL is a very convenient language for users to access data and has become a standard query language, it’s actually an extremely limited language for software developers and leads database management systems and their users into very bad constraints.

Ironically, very few large applications built on top of SQL databases still offer SQL interfaces for their end-users. Instead, end-users interact with the database through an application user interface. If SQL is no longer the interface that the end-users see, the query language just becomes a development and administration choice.

Consequently, instead of referring to these DBMS products as "relational", which is a theoretical model, this paper will refer to these products as "one size fits all” or “SQL” databases. The solutions that these products provide are optimized for the most lucrative applications of the 1970’s. These applications generally have the following characteristics:

Relatively static data – E.g., products and customers are not created in large quantities every day. Once the database is built, the amount of data added on an hourly or daily basis is relatively small.

Binary "unstructured" data is almost always stored external to the database or as “BLOB”s. Data with complex or dynamic structure is simply considered unstructured.

"Manageable" cardinalities – E.g. hundreds of products, thou sands of customers, less than 100’s of gigabytes in total.

Query by attribute – Data is fetched based on values, rather than following relationships between one object (or row) and another. Relationships are represented using special values (primary and foreign keys), but there are few "deep" queries that require traversal through many relationships.

Small, short transactions – Each transaction changes a small amount of data, e.g. a customer id, product id(s), payment and date, and is committed to the database quickly.

Centralized processing – Updates and queries are done through a server, either online or in batches.

Highly administered – Database administrators are available to manage the data behind the scenes.

Applications that have these characteristics fit well into the SQL database management model, but many applications, especially modern ones, have more complex requirements. For these applications, one cannot configure the RDBMS solutions to meet the requirements without making severe compromises and sacrifices.

Consequently, rather than choosing the appropriate database management solution, requirements of the applications are often limited to what the database and the available hardware will support. If the database can’t be changed, the requirements of the application must. For many applications this is undesirable, but for some it is impossible.

This is not because the RDBMS products are inferior, but rather that they’re an incorrect tool for the problem, just like using a hammer is a terrible way to drive a screw and vice versa. Much of this “impedance mismatch” comes directly from organizing data into tables, but much of it comes indirectly from the constraints that tables and SQL put on the RDBMS architecture.