Relational database management systems aren’t the only game in town. A growing number of Linux and Windows developers are turning to a more synergistic alternative: the object-oriented database. Among other benefits, an object-oriented database stores objects “as-is.” There’s no object-to-relational translation layer.
The computing world appears fixated on relational databases as a persistence technology. To most, a database such as Oracle, MySQL, or PostgreSQL is an obvious choice, even if there’s an “impedance mismatch” — conflicting philosophies, structures, and interfaces — between the tenets of so many object-oriented programming languages and traditional, tabular schemas.
But relational database management systems (RDBMS) aren’t the only game in town. Indeed, a growing number of Linux and Windows developers are turning to a more synergistic alternative: the object-oriented database. Among other benefits, an object-oriented database stores objects “as-is.” There’s no object-to-relational translation layer.
When the programming language and the database are of the same mind — think “objects” — persistence and retrieval of even the most complex objects can be as simple as three or four lines of code.
One of the most popular object-oriented databases (OOD) is db4o. db4o is open source, is available as Java or C# source code, and can be packaged as a single .jar file and a single .dll for Java programmers and .NET developers, respectively. Consequently, db4o is easily integrated and distributed with Java and. NET applications.
Better yet, the db4o application programming interface (API) isn’t overrun with complex classes and legions of methods. Most interactions occur through the db4o ObjectContainer class, which represents the actual database. The ObjectContainer interface defines only ten methods, yet provides the bulk of all common database manipulation capabilities, including inserts, searches, updates, and deletes. With db4o, you can master database coding in a surprisingly short amount of time. And if you need advanced features, you can instantiate an “extended” ObjectContainer, which exposes more methods to provide more control over the internal parameters and machinations of the database engine.
Of course, being object-oriented gives db4o some significant advantages that should not be ignored. First and foremost, objects are stored “as-is”, without any object-to-relational translation layer, either explicit or invisible. Database manipulations are performed by method calls, not strings of SQL that are passed to an SQL interpretation and execution engine. You don’t have to create and maintain schema definitions for mapping object structures to relational tables. Nor do you have to pollute your object definitions with ‘foreign key’ fields in order to model object relationships across a set of relational tables. In short, your objects’ structure is the database schema.
And, last but certainly not least, db4o is fast. Because db4o for Java and. NET are written in the native languages of those platforms, there are no language or runtime “boundaries” to cross (from process to process, say) as the database executes. For comparison, Table One shows the results of recent benchmarking of db4o and some well-known RDBMS packages.
Table 1. Performance of db4o as compared to other relational databases. Each number in the above table indicates by what factor db4o outperforms several popular relational database systems for a variety of database operations. A factor of 1.0 means the database performs on par with db4o. Larger numbers indicate how much better db4o performs. (These numbers were taken from the Pole Position open-source database benchmark. Further information can be found at http://www.db4objects.com/about/productinformation/benchmarks.)
As indicated, db4o easily holds its own against such systems in a majority of database operations.
Kicking the Tires
db4o’s refreshingly terse API is best illustrated via an example. Suppose you’ve written a monitoring package for systems on your local intranet. Computers being monitored run a small client stub that communicates with a master control server over TCP/IP. From the control server, you can choose to collect data from any client. This data is a stream of samples taken at a fixed interval for a chosen number of data points. Data is gathered in the context of a monitoring session.
Given that specification, you might define a class to model such a session like the code in Listing One (in Java, although the implementation can just as easily be realized in C#). (For brevity, Listing One doesn’t show the methods associated with MonitoringSession, nor does it show how the data points are collected.)