Page 2 of 6
setOfGoodCustomers = setOfAccounts.query(account.inGoodStanding());
While several of the existing object databases are capable of processing such a query style in C++ and Smalltalk, it is difficult for them to do so for larger (say, 500+ gigabytes) collections and more complex query expressions. Several of the relational database companies, such as Oracle and Informix, will soon offer other, SQL-based syntax to achieve the same result.
An object-oriented language aficionado would say persistence and type are orthogonal properties of an object; that is, persistent and transient objects of the same type can be identical because one property should not influence the other. The alternative view holds that persistence is a behavior supported only by persistable objects and certain behaviors may apply only to persistent objects. The latter approach calls for methods that instruct persistable objects to store and retrieve themselves from persistent storage, while the former affords the application a seamless view of the entire object model -- often by extending the virtual memory system.
An extension of canonicalization addresses language-independent object representation. If objects can be represented in a language-independent fashion, it will be possible for different representations of the same object to share the same persistent storage.
One mechanism to accomplish this task is to introduce an additional level of indirection through an interface definition language (IDL). Object database interfaces can be made through the IDL and the corresponding data structures. The downside of IDL style bindings is two fold: First, the extra level of indirection always requires an additional level of translation, which impacts the overall performance of the system; second, it limits use of database services that are unique to particular vendors and that might be valuable to application developers.
A similar mechanism is to support object services through an extension of the SQL. Relational database vendors and smaller object/relational vendors are proponents of this approach; however, how successful these companies will be in shaping the framework for object storage remains to be seen.
But the question remains: Is object persistence part of the object's behavior or is it an external service offered to objects via separate interfaces? How about collections of objects and methods for querying them? Relational, extended relational, and object/relational approaches tend to advocate a separation between language, while object databases -- and the Java language itself -- see persistence as intrinsic to the language.
Rick wrote this book way before Java was en vogue and has an excellent treatment of various styles of object storage, from API to distribution to actual disk layout. Rick has gone on to play a important role in the definition of JDBC API.
This book is a collection of papers written on data storage, but has a bias toward demonstrating that object/relational systems will win out over pure object systems. Nonetheless, most anyone who is someone in this business has contributed to this book, so it's worth a look.