works on demand. To meet all these new challenges, the best answer, though not the easiest, seems to be represented by object-oriented database management systems (ODBMSes).
ODBMSes are not trivial packages. They're complex and expensive, and using them requires a change in procedures, habits, even attitude. But more and more organizations are choosing ODBMSes to help them do the jobs they need to get done. Some reasons include the growing presence of object-oriented programming models in the client/server realm, including COM, DCOM, and CORBA; the inability of traditional, SQL-based, relational database management systems (R
DBMSes) to address complex data and multitiered architectures; and the semantic mismatch between SQL and more modern, component-based languages, such as Java, ActiveX, and C++.
For this report, BYTE looked at
three of the major
players: Object Design's ObjectStore, O2 Technology's ODMG, and Versant Object Technology's Versant. Each represents a somewhat different approach to building an ODBMS, but all are compliant with the Object Desktop Management Group (ODMG) standards. All are available for both Unix and Windows NT platforms, and all include full support for C++ and have either beta or shipping interfaces for Java.
We installed these products on NT-based servers and exercised their capabilities, seeing what they were individually best suited for and evaluating the support available to the user and the network administrator. In our evaluations, we placed considerable emphasis on the ease of development and deployment, since these products are merely building blocks that y
ou have to put together as efficiently as possible. We noted how well they serve up data for Web- and Internet-based applications, and what use they made of Java.
Our original plan included extensive performance testing, but we learned the hard way that this wasn't such a straightforward task. We were unable to create useful and comparable tests in the time that we had available (see the sidebar "Missing the [Bench] Mark").
I Object to This Relationship
Before getting into the specific products, let's review how ODBMSes differ from RDBMSes. The relational database model was built on the concepts of algebraic set theory, monolithic lookup tables, and a simple ad hoc query grammar, which was eventually standardized into the omnipresent SQL.
ODBMSes, in contrast, are centered around the concepts of persistent storage in object-oriented programming (OOP) languages. In essence, this means that classes, attributes, and instances of objects can be represented within a database in the same
way that they're represented in OOP languages. Also, they can be stored and retrieved by applications as needed in their natural form without needing to be altered to fit into a relational table.
While the pure, theoretical RDBMS model is versatile enough to accommodate any object type, data structure, or distributed architecture, when it comes to practical implementations and real-time performance issues, the relational model starts breaking down and becoming less than optimal. Why? Because most modern client/server and other complex software packages are programmed in terms of objects, and objects just don't fit neatly into relational tables. More often than not, the only solution for this problem is to create a separate table for each distinct class that exists in the particular database model that's being developed.
Unfortunately, once you have a number of classes, you need to take data from many tables to complete most queries, and the overhead becomes significant. Doing a SQL JOIN to pool
data from multiple tables can involve intensive algebraic computations when you're working with large amounts of data. The more complex, hierarchical, or interrelated object-oriented data becomes, the harder it is to coerce the relationships into rows and columns, and it becomes ever harder to read and update such data.
Object databases remove this layer of complexity and theoretical discrepancy, and, in fact, their architecture lends itself more readily to distributed computing and local caching than does the RDBMS model. It's often said that ODBMSes exhibit terrible performance on simple queries and don't support ad hoc queries. Indeed, straight queries in a relational database that only require pulling data from one table and a few columns might run faster than an equivalent ODBMS transaction. However, the latter have been observed to perform from 100 to 1000 times faster on complex queries where RDBMSes required a JOIN. (For more on the advantages and strengths of ODBMSes, see the Features article "
Debunking Object-Database Myths".)
The Development Process
While ODBMS products have proven their reliability at the enterprise level, they have yet to reach that maturity on the interface and development side. When developing a data model in an ODBMS, you must come to terms with many different data structures. Some of these constructs -- array, set, cursor (a pointer used to scan through a grouping of objects), or bag -- are familiar to the seasoned programmer and are also used in RDBMS development. Others are unique to ODBMSes and are useful for optimizing performance.
For instance, a
segment
is loosely defined as a physical grouping of objects as a unit of a larger database. It's useful when you have objects with a few large attributes (e.g., an employee object with an associated binary image). If you group the larger attributes of different objects together in a segment, the system can scan both large and small objects faster -- the large ones because they're all in the same ph
ysical location in storage, and the small ones because the size of each object in storage has decreased.
Vaguely similar is the cluster concept, another way to group like objects or attributes strategically. Clusters work more at the logical level, placing certain objects with stronger interrelations (for example, children in a tree) closer together. Each of the tested ODBMSes has these constructs in some form, although they're certainly not interchangeable. To some extent, a lot of these optimizations are automated implicitly upon the creation and population of a database (particularly in Versant). But to gain the finest control, especially for mission-critical applications, you must define them explicitly.
Versatile Versant 5.0
Versant gears itself toward the higher-end enterprise market, with emphasis on transaction granularity and fault-tolerance. Despite its strengths in these areas, it's quite lacking in development aids, and its user interface is primitive.
Unlike many commer
cial ODBMSes, Versant is based on the object-server model, not the page-server implementation found in ObjectStore (O2's ODMG, meanwhile, uses a hybrid). With a page server, the smallest unit of data is of a fixed size (usually about 4 KB), while an object server deals with logical objects, which are often smaller. When objects are small, this object-server architecture permits a maximum of concurrency for servers with a heavy transaction load.
Versant offers a fault-tolerant server, with industry-leading solutions for synchronous database replication and transparent master/slave mirroring. These features are deeply rooted in the ODBMS architecture, thus requiring a minimum of code-grappling to configure.
VersantWeb, a companion product aimed specifically at Web applications, is relatively less expensive than its two competitors while still offering vital functionality and interoperability with all major Web-server APIs.
Although Versant excels in versatility and reliability, it fails badly
in terms of ease of learning and administration. The C++ API was easily the most complicated of the three we tested, and it also had perhaps the least readable documentation and reference. The graphical tools are restricted to a simple DBAdmin utility, which offers little beyond the most basic database-administration operations. And there are no RAD tools available.
We didn't test Versant's Java interface, which hadn't yet been released, but it's reported to have all the functionality of Versant's standard C/C++ interface. We think it will probably provide an easier development environment.
Who's Minding the ObjectStore?
BYTE has already looked at Object Design's
ObjectStore 5.0
, a cutting-edge ODBMS that offers the best-case scenarios for development, architecture, and rapid time to market (see "What's in Store for the Web," August BYTE). ObjectStore is fundamentally different from the other two products, using virtual memory mapping rather than inheritance and uniq
ue IDs to regulate and manage each object.
Where Versant and ODMG require each newly created object to be a subclass of the generic base object class, ObjectStore does not. This saves an average of 64 bytes per object of overhead, a small gain that really adds up for enormous multigigabyte databases.
In addition, ObjectStore is the
only ODBMS
we tested that offers ActiveX support, clearly a big advantage for Windows NT distributed development. Perhaps the most impressive feature of ObjectStore is its suite of visual tools for developing applications and administering existing databases. Inspector 2.2 is an advanced utility that allowed us to edit data, rearrange a database's physical organization, and design queries. All this is contained in a user-friendly point-and-click environment, which uses a familiar spreadsheet-like layout to display data. You can also evaluate and debug the often-complicated database schema file using Inspector.
Another useful tool in the Obje
ctStore arsenal is the Performance Expert, an analytical utility that examines an ObjectStore application or architecture and suggests optimizations, as well as giving detailed performance information.
With ObjectStore, you can develop in both C++ and Java, and your Java code can access C++ objects and methods within the database. In terms of its C++ API, ObjectStore sported the most streamlined code with the least amount of required structures, macros, and cryptic class instantiations to construct a simple database and object model. Unlike the other two products, however, there's no Smalltalk interface.
Object Design's support for ObjectStore is very impressive. It's standard practice for an engineer to spend a day or two with a customer to help install the product and resolve any questions.
The French Connection
For reasons that escape us, a surprisingly large number of ODBMS products originate in France, including O2 Technology's ODMG 5.0. For the developer, the ODMG 5.0 database
server presents two different faces. On one side is a competitively priced server for Unix platforms, offering O2Look and O2Tools, nice rapid application development (RAD) tools, and graphical interfaces to its complex database system.
Alas, there's no visual interface whatsoever on the NT side of things. This is particularly unfortunate, given that a significant amount of advanced client/server development is performed on the Windows platform even when the target server might be a Unix machine.
On the positive side, O2 boasts the implementation of its own 4GL, called O2C, which allows for advanced and simplified programming and dynamic memory and object management within a syntax and environment that are fully compatible with plain old ANSI C.
Furthermore, O2 Technology has been working with top CORBA developers to produce its own O2Corba add-on for ODMG 5.0, which gives a full interface to the popular CORBA implementation of distributed object architecture. In addition, O2 has recently de
veloped a high-tech server model, called "adaptive locking," which permits a hybrid of page and object locking for concurrent transactions.
Objects stored in the O2 database are language neutral. This means that if a particular object is developed in Smalltalk, it can be accessed or manipulated by a Java application and vice versa.
Good Support
One final word about deciding on a package like one of these: Help from the vendor when you need it is critical for enterprise software, including ODBMSes. All three products we tested offer outstanding support, which sometimes includes contract accounts and extensive on-site support and training. And this includes not only technical support, but also a future commitment to compatibility and standardization.
The vendors have come a long way in developing better front ends in which existing SQL queries can be executed and traditional relational concepts ported to an object framework. It's good to know that when you have to switch, you can rely
on good tools that build on what you already have.
Product Information
NeoAccess 5.0....................$ 750
NeoLogic Systems
Berkeley, CA
Phone: 510-524-5897
Internet:
http://www.neolo
gic.com
Enter 1097 on Inquiry Card.
Information on
this product
and similar products (data management)
The Object Is to Manage Data
