Summary
In a recent IBM developerWorks article, Ted Neward introduces db4o, a Java object-oriented database. Rather than aiming to replace a relational database, db4o can serve as an effective solution in specific problem domains, according to Neward's article.
Advertisement
As developers gain increasing real-world experience with the leading object-relational frameworks, including Hibernate and the JPA, some will undoubtedly look up and ask whether O/R mapping, and relational databases, always present the best solution in a problem domain. However, considering the rich choices in relational databases, and the plethora of development tools aimed at working with a relational database, few developers will consider non-relational object persistence as an alternative.
In his recent IBM developerWorks article, The busy Java developer's guide to db4o: Introduction and overview, Ted Neward asks his readers to consider object-oriented databases not as replacement for relational databases, but as a possibly more suitable solution in certain use-cases:
If the goal is a true loose coupling between components (services, tiers, whatever the nom du jour), then it follows that the only degree of coupling is between the caller of a service and the exposed API (or XML types, however you look at it) of the service... In essence, your persistence options are an implementation detail. It follows that the persistence options available to you in a wider variety of scenarios have grown by an order of magnitude.
One of the difficulties of even the most sophisticated O/R mapping solutions is representing truly rich object models. While the best frameworks can certainly model rich object models, they do so at the cost of trade-offs in the relational model of the database, according to Neward:
It's hard to get really excited about building a rich domain model (a la Martin Fowler or Eric Evans's respective books) if you're then going to have to either compromise it in order to match an existing database schema, compromise the database's ability to carry out its operations to support the object model, or both.
But what if you didn't have to make any compromise at all?
Such compromises may not be required when persistence is handled by an object-oriented database, such as db4o, the topic of Neward's article. In addition to Java,
db4o is available for C# and other .NET languages, and its data format is cross-compatible between the two, making Java objects available to similarly-defined .NET classes... plus db4o supports what they call "Replication," which allows a db4o instance to replicate data from its own storage format into an RDBMS.
Neward points out that db4o is not meant as a relational database replacement:
db4o looks to solve a particular set of problems, not to become the single-stop, one-size-fits-all solution to every persistence problem. In fact, this is what makes db4o refreshingly different from the OODBMS options the first time around: it's not out to convince production IT staff that it's a good idea to completely abandon their investment in a relational database.
Neward also notes that some persistence features, such as object identity, are implemented differently from how a relational database would provide similar features, thus requiring developers to adjust their thinking to the OO database's way of doing things.
In what situations would you use on object-oriented database? What is your experience using such databases in the context of enterprise applications?
Relational databases are really good for storing data that needs to be used in many contexts but that often what we (developers) end up doing with them is storing application configuration and state along-side the actual data. Lately I've been wondering if this makes sense. Do we need to put application configuration in the same place as the data? Has anyone reading this ever tried splitting the application specific persistence from the 'real data' database. What I mean by real data is the kind of stuff that goes into a data warehouse or is used for analytics and reporting. Application specific data would be things that are only interesting to the application.
If this kind of separation makes sense, it seems that an Object-Oriented database might make sense for a Java app's application specific data. I have no experience with OO databases though. I wonder how easy it is to browse and maintain the data.
One thing that is mentioned in the article (at the bottom) is that you "get duplicates". Is there a pattern or mechanism in db40 or other OO databases that can be used to address race conditions? This is one of the nice things about relational databases. You can use the transactions and uniqueness constraints to good effect in distributed applications.
… pointer-based techniques are optimized for very specific "search routes" or viewpoints. However, for general-purpose queries on the same information, pointer-based techniques will tend to be slower and more difficult to formulate than relational. Thus, navigational appears to simplify specific known uses at the expense of general, unforeseen, and varied future uses. (http://en.wikipedia.org/wiki/Object_database)
The more convenient OO databases persist objects that get modified automagically and look like an embedded database and therefore are more convenient to work with from a programmer’s perspective. With the popularity of OLAP handling ad hoc queries in bigger companies nowadays anyway, OO databases might work nicely in well-defined OLTP environments.
> Application specific data would be things > that are only interesting to the application. > > If this kind of separation makes sense, it seems that an > Object-Oriented database might make sense for a Java app's > application specific data. I have no experience with OO > databases though. I wonder how easy it is to browse and > maintain the data.
I experimented with db4o to do pretty much exactly this - creating a small DB and the library code to manage userNames, groups, passwords, permissions, esig and audit restrictions, etc. Data that was specific to a 21CFR-11 module, not data warehouse stuff.
Db4o was truly wonderful for this. The existing relational DB code (pre-Hibernate, largely pre-Spring, so this isn't a completely fair comparison) was cumbersome, hard to use, just plain huge (>1000 classes, many man-years in development) and grossly overdesigned.
I largely reimplemented it in less than 1 week with a couple of dozen classes. Using Db4o was a delightful breath of fresh air.
I didn't look into any other OODBs, they'd probably be good for this type of application too.
> Db4o was truly wonderful for this. The existing > relational DB code (pre-Hibernate, largely pre-Spring, so > this isn't a completely fair comparison) was cumbersome, > hard to use, just plain huge (>1000 classes, many > man-years in development) and grossly overdesigned. > > I largely reimplemented it in less than 1 week with a > couple of dozen classes. Using Db4o was a delightful > breath of fresh air.
Let's say that after you implemented this, you discovered a bug that was putting bad data in the db4o instance. How hard would it be to clean up? Would you have to write more code or is there some kind of toad-esque interface for the data? Maybe I should just check it out but it's number umpteen on my list.
> I experimented with db4o to do pretty much exactly this - > creating a small DB and the library code to manage > userNames, groups, passwords, permissions, esig and audit > restrictions, etc. Data that was specific to a 21CFR-11 > module, not data warehouse stuff.
On a side note, I had to do some of this backed by LDAP not long ago. That was a nightmare. Bad APIs to begin with but not being able to commit or rollback is a real PITA. You never know how much of your work went though in a failure.
> is there some kind of toad-esque interface > for the data?
Yes - there is a toad-esque program. Unlike Toad, it is provided by the db4o people, only works for db40 (not other databases, in fact, as versions of db40 upgrade you need to upgrade this program) and there is only one offerring (TOAD has competitors like Squirrel). So browsing / debugging / minor fixing support exists, but is weaker than mainstream SQL RDBs.
Objectivity/DB has been around for nearly 20 years and is currently at version 9.3. Objectivity/DB provides complete support for ACID transactions in a multi-threaded and/or multi-process environment. Objectivity/DB provides a feature called MROW, "multiple readers one writer", that allows readers access to the latest versions of objects that are available until the writer commits its transaction.
Objectivity/DB exists as a federated database. Within the federation, there can be thousands of individual databases that resided on heterogeneous hardware platforms around the network. Any application on any machine on the network can access any object in the federation and any byte-ordering issues are resolved.
Objectivity/DB is scalable down to embedded systems and up to massive-volume (10^24 bytes) systems distributed across the network.
Objectivity/DB does not use an O-R mapping layer. It is a pure object-oriented database. It also has no database server, per se. It relies on a software kernel that is linked into the application, a single lock server process running on the network and then page servers running on each system that hosts data. All of the "work" is performed in the kernel.
If projects are involved in oo-Analysis, oo-Design, oo-Implementation, an oo-Database usually makes more sense than people realize.
Previous Topic
