Focusing on open APIs for enterprise applications

Open Web Magazine

Subscribe to Open Web Magazine: eMailAlertsEmail Alerts newslettersWeekly Newsletters
Get Open Web Magazine: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn

Open Web Authors: Jnan Dash, Jayaram Krishnaswamy, Bob Gourley, Kevin Benedict, Pat Romanski

Related Topics: Open Web Magazine, MySQL Journal

Open Web: Article

db4o in the Mirror of JPA/EJB and Hibernate

When or why should I use an object database?

There are many studies available that compare the benefits of object database management systems (ODBMS) and relational database management systems (RDBMS):

  • Because of their independent representation, relational database systems are ideally suited to various access modes. Besides being simple to create reports on relational data, the management of large amounts of data is very fast.

    Nevertheless a number of disadvantages caused by the impedance mismatch occur when mapping objects to a relational database. These disadvantages create opportunities for object database systems:

  • Object databases enable easier persistence code in the context of complex object structures. Object navigation and the elimination of "joins" are an advantage in some cases.

    Every advantage generally involves a disadvantage. This applies to relational database systems with their OR mappers as well as to object database systems. Specifically, the mapping of deep and complex object structures with OR mappers isn't easy and can be a challenge to maintain. On the other hand the administration and reporting of data structures in ODBMS is not as sophisticated. We'll go into that later.

    For these reasons there have been many discussions lately about which is the ideal solution. Gavin King is defending the relational world against all challengers with his impressive flagship product Hibernate. In May 2007, King published a long blog post called "In Defence of the RDBMS," portraying solutions such as Active Records from Ruby on Rails or object database systems as unreliable.

    Famous .NET and Java developers like Ted Neward argue against this point because it's obvious that there's absolutely no need for the relational world and its ORM solutions to defend themselves since they completely dominate the enterprise world. Hence Ted takes a "relatively" neutral position arguing that there's always a "right solution for the right problem" and that the world of persistence could use a little more versatility than just RDBMS (e.g., Oracle or MySQL) + Hibernate.

    But there must be a reason for the attacks on the ORDBMS world. So let's take a look at the application areas.

    One of the first things to do before choosing a database system should always be an analysis of the data format required. In doing so, the following questions will arise:

    1.  Do I need the data in class-independent or relational format? Do I have to access the data via different views, i.e., different classes (e.g., also in different languages)? Do I need lots of OLAP-style reports? Are there many departments with different domain models accessing the data?

    2.  Do I need cluster architectures out-of-the-box and a stringent and secure administration of the database system?

    These are some of the core questions that every project leader should ask himself. If most of the answers are "yes," it's obvious that a high-performing relational database system is the only feasible choice.

    It's a very different story if these questions can't be answered"yes." In many cases persistence is only one aspect and not a primary requirement of the application. This means that the requirements regarding persistence aren't too high. Many of the LAMP or Ruby-on-Rails applications are developed as"single-user" applications. Many applications deploy one single (e.g., Java or C#) domain model, where the database doesn't need an administrator and data access is nowhere near the range of a big portal. In this case one can consider an object database system.

    Another example is embedded applications. All elements of both questions 1 and 2 can clearly be answered"no." It's here where db4o becomes relevant.

    db4o and the Competition
    db4objects was founded in 2004 and achieved close to 2 million downloads and 30,000 registered users in just two years. The database system isn't geared for big enterprises or big portals with highly scalable multithreaded access. db4o is a lot more successful in BMW cars, Seagate hard disks, Ricoh office equipment, and Bosch robots. But the application area is much broader than just devices.

    We'll compare db4o's features with those of OR-Mappers + RDBMS (e.g., Hibernate or JPA/EJB 3 with MySQL). This is definitely a comparison of apples and trumpets, though readers who are familiar with EJB/Hibernate might be able to assess the ODBMS features better.

    System Environment
    db4o itself is just a small Java JAR or MS.NET DLL library of about 600K. And it only requires a few system resources. Usually a few megabytes of RAM are sufficient to work with db4o.

    db4o stores Java as well as .NET objects, so any .NET-compatible language such as C# or Visual Basic can be used.

    A db4o system can't be administered externally. Administration is only possible via program code, which has many disadvantages but also a few benefits: The system can be installed quickly. From download to integration into the classpath to storing objects, db4o needs less than two minutes.

    Another interesting feature is that db4o is very strong in mixed environments. For example, applications written in Java and C# can access the same database. The Java version also enables Unix versions of db4o.

    Object database systems are often criticized for not having a data-independent schema because the object class, in essence, is the database schema. This would make class-independent data processing impossible. In db4o this is bypassed by the concept of aliases. Using package and class aliases even names can diverge. Because class methods can differ and are ignored by database systems, it's no problem using similar, if unequal classes, e.g., in Java or C# to access the database.

  • More Stories By Stefan Edlich

    Stefan Edlich is professor of software engineering at the Technical University of Applied Sciences in Berlin. The focus of his research includes enterprise applications, object databases, and mobile applications. The results of his research have produced many books on open source, Web frameworks, J2EE, and db4o. Stefan is organizing the object database conference 2008.

    More Stories By Daniel Oltmanns

    Daniel Oltmanns is a research assistant at the Technical University of Applied Sciences in Berlin and an expert in the field of AJAX-technologies, databases, and Spring-architectures.

    Comments (0)

    Share your thoughts on this story.

    Add your comment
    You must be signed in to add a comment. Sign-in | Register

    In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.