ools, such as C++, wh
ich itself is not fully standardized.
Each product tested for this review had entirely different C++ data structures to represent a basic object with string attributes of random length. Moreover, each product had its own C++ macros, which were needed to initialize the database, populate it with replicated objects, and begin and end a transaction. And, of course, these macros don't behave the same for each ODBMS product. For objects such as a database segment, a large pointer, a record cursor, and a static reference, there were often vastly different implementations of each for a given product. For these reasons and more, porting a generic pseudocode application with any degree of realistic complexity to each ODBMS could not guarantee a reasonable level of parity across these very different products.
Not only was the basic creation of databases and objects not consistent, the semantics of a transaction and the database's model of locks and privileges employed during a read or write
were also inconsistent. To each vendor's credit, all the ODBMSes tested had a well-defined and highly flexible system of locks and transaction-behavior parameters. But, again, there was no easy way to equate a particular scheme that would be the same for each database. And while each product supports Object Query Language (OQL), that isn't always the best method for querying the database, and products allow you to not use OQL at all in performing reads and writes on the ODBMS.
Most of these benchmarking issues stem from the general complexity of databases. Even relational DBMSes tend to use proprietary language additions to maximize performance and efficiency in an enterprise application.
Thus, the bottom line is that NSTL could not, under any practical or realistic circumstances (and in the time available), obtain performance data with which to compare real-world implementations of the ODBMS products that are reviewed in this article. We concluded that to create tests that would fairly compare t
he three systems would require, at the very least, three separate development efforts, and even then we would have to make choices that would call some results into question. Ralph Waldo Emerson may have said that consistency is the hobgoblin of little minds, but BYTE simply can't make performance comparisons without it.
There's hope on the horizon, though. The ODMG has a better chance of working toward a Java common standard for the ODBMS world before vendors diverge in their various implementations of a Java API. If Java can be standardized here, its ease of development and strict object-oriented semantics relative to C++ will give it a good chance to become the premier language of choice for ODBMS development. Applications written in Java for a particular ODBMS are much more easily portable to another ODBMS than they are if they're written in C++. Moreover, Java melds very tightly with the ODBMS concepts -- something SQL could never do. This will also be an important factor if ODBMSes are to gain wid
espread acceptance in the future of enterprise data handling.
Missing the (Bench)Mark
