Object Oriented Database Learning Center

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

Table of contents:

Object Oriented Database vs Relational Database

How to Avoid the Wall

As we have seen in theory, in benchmarks, and in real production applications, the relational wall is real. It occurs dramatically in performance, with execution time rising rapidly, in fact exponentially, with increasing complexity, quickly reaching 100x slower than ODBMS, and beyond. The wall also exists in dramatically increased complexity, causing increased software development and maintenance cost, and in dramatically reduced flexibility and extensibility.

This wall can appear suddenly and unexpectedly when users take prototy pe applications and attempt to deploy them. The resulting growth in information, users, and complexity can bring them face-to-face with the wall. The result is typically failure.

To avoid such failure, users must anticipate where the relational wall will appear, and prepare for it. As long as they hold complexity of information down to very simple, fixed-length, table-structured data, with short, simple, localized operations, central server storage, and limited growth in size and numbers of users, they are safe within the RDBMS world. Exceeding any of these limits will bring them, soon or later, to the relational wall.

The key is to use the right tool for each job. Look for the following telltale signs that the relational wall may be closer than you think:

1. Use of Objects (C++, Java, Smalltalk, etc.), which requires mapping to RDBMS tables. Such mapping code may grow to 1/3 to 1/2 of the application, increasing development cost. Worse, with each design change, and maintenance change, those changes are amplified by the mapping code and make maintenance dramatically more expensive, in some cases prohibitively so. While the RDBMS requires you to continually work at the flat, primitive level, the ODBMS allows you to work at any level, up to and including the highest, application level.

2. More than 2 or 3 levels of Joins. This is a red flag, since joins are so slow in an RDBMS, and orders of magnitude faster with direct relationships in the ODBMS. The more joins (relationships), the more you'll benefit from an ODBMS.

3. Many-to-Many Relationships. The RDBMS model lacks support for any relationships. Simple one-to-one, and to a lesser extent, one-to-many relationships may be modeled, at the cost of extra application code to maintain them, and loss of performance. Many-to-many relationships typically become too complex to be usefully or practically modeled in an RDBMS.

4. Hierarchy traversal. If you application includes any hierarchy or multi-rooted network creation, update, or traversal, RDBMS performance will be extremely slow, and ODBMS exponentially faster.

5. Varying Sized Data structures. Structures such as time-series and history information, or any other structures that dynamically varying in size, are poorly modeled by fixed size tables. In an ODBMS they're directly supported, making development and maintenance far easier, and performance much higher.

6. Nested or Complex data structures. The RDBMS requires and supports only simple, flat, rectangular tables. Any other shape of structure, any complexity, and any nesting will require complex modeling tricks in the RDBMS, making implementation difficult, error-prone, and slow. In and ODBMS, these are supported directly.

7. Distributed (non-centralized) Deployment environment. The RDBMS borrows its architecture from the mainframe, storing data and performing all operations on a central computer (server). If your environment includes multiples PCs, workstations, servers, the ODBMS will prove far superior by providing a single logical view over all databases on all servers.

8. Heterogeneous Computers, operating systems, languages, and networks. RDBMSs typically run in one environment only and, at best, provide only remote thin-client access from different architectures. With the ODBMS, objects may reside and execute transparently on any of the common architectures, allowing you to leverage existing investment in hardware infrastructure and training, to incrementally add new technology equipment along side old, and to support all levels of users, from C++ gurus to end-users clicking buttons on PowerBuilder or Visual Basic forms, all sharing the same objects in the same databases on the same shared servers.

9. Flexibility and Extensibility, in both physical and logical design. The RDBMS offers only one physical structure, centralized tables, and logical structures are limited to similar, flat table subsets (views). The ODBMS allows any logical structures, dynamically mapped to the desired physical structures, in multiple databases, with multiple levels of clustering, across multiple types. All of this is hidden from users and applications by the single logical view, so that dynamic, online changes to the physical layout, including moving objects and databases, reclustering, adjusting locking granularity, etc. Similarly, logical changes may also be made online, via schema evolution and instance migration, all new objects and subtypes of old objects to be added, old objects to be modified, with changes made automatically to online production databases. Features such as versioning can model history and alternatives. Object encapsulation allows fixing one object without breaking the rest of the system. Inheritance allows reusing old objects, even when they don't do exactly what you need, by specifying only the difference.

10. Integrity and Scalability. RDBMSs support integrity only at the primitive, flat, tabular level. All data structures above that are left to the application, and integrity is at the whim of each of the applications. With ODBC GUI tools, integrity is at the whim of the end users, that are also forced to work at the primitive, flat level. The ODBMS supports integrity at all levels, with object operations automatically maintaining integrity rules, and enforcing them across all applications. Even ODBC GUI tools, used with an ODBMS, support access to such high level objects and their operations, and the ODBMS can limit end users and groups of users to only certain objects and operations. Scalability in an RDBMS is limited by the single, central-server bottleneck, and by the capacity of the server machine, which must support all users. The distributed ODBMS architecture avoids any single bottleneck, allowing scaling in both clients and servers, adding users without slowing down others, incrementally adding commodity, inexpensive servers to improve performance as needed, supporting unlimited numbers of users, and up to millions of tera-objects, which may be up to many gigabytes.

The final consideration is one of risk. Some, because they are familiar with the older RDBMS companies and products, might deem them to be lower risk. If, however, you're application has any of the above characteristics, or might grow to include any of them, then the risk with the RDBMS is major problems, even failure, in production, while the ODBMS can avoid that. The risk is not in the DBMS product you buy, assuming you buy one that has referencable production users (such as those cited above). Rather, the risk is in the application you develop. If you use objects with an RDBMS, that risk is magnified by the need to add a layer mapping from objects to tables, by the maintenance cost of that layer, by leaving the application-level structures and integrity maintenance to individual applications. With an ODBMS, no mapping layer is required, and the ODBMS subsumes the common high-level model and integrity maintenance across all applications.

Dr. Andrew E. Wade, Ph.D., a founder of Objectivity, Inc., as well as co-founder of ODMG and author of ODMG-93 and many articles.