Getting Started With Object Databases

• Download demo project - 390.67 KB

Introduction

Object databases allow you to store business objects intact, without the need for object relational mapping. They are typically used as an embedded database, though most vendors have a network version available, where clients can access a running server via TCP/IP. Object databases are an exciting technology that promise to change the landscape of data storage. In this article, we will study some of the benefits of using an object database, how they compare to relational databases, and finally, we'll provide a programmatic example to help you get started using object databases in your next project.

This article is not intended to be an introduction to programming; I am assuming you have a good familiarity with Java or C#. Also, for this article, our sample application will use the object database solution available from db4objects. You can learn more about them here.

For the sample application, you will need to download the latest version of the db4o database. To do this, go to db4o.com, and click on "Product Test Drive". We will be writing code for the sample application in C#. Feel free to use any IDE you choose; even a simple text editor will suffice. If you need a great C# IDE, SharpDevelop is a free IDE that allows you to code in languages such as C#, VB.NET, Java and more.

Some Background Information About Object Databases

Before we embark on a more technical discussion about object databases, let's cover some basic background information about object databases. Object databases got their start towards the late 1980s, but until a few years ago, only saw success in a few niche markets; namely telecom, scientific, and financial applications. Object databases today have grown exponentially, thanks to their implementation in various OOP languages like Java and C#. Object databases have also grown thanks to the popularity of OOP languages themselves.

The schema for an object database takes form naturally as your objects are persisted. There is no need for database administration tools, a database administrator, or even an extensive knowledge of relational database theory. If you have a good object model, you have a good database schema. Period.

Object databases boast about extremely high levels of performance. One database vendor claims speeds up to 44x faster than object-relational mapping using HIbernate with a MySQL backend (db4objects 2006). Object databases also boast about the highest ingest rate ever recorded in a commercial database (over 1 Terabyte per hour), and the largest database (over 1000 Terabytes at Stanford Linear Accelerator Center) [Wikipedia 2006].

Object databases are standards based. The Object Data Management Group (ODMG) was a consortium of object database and object-relational mapping vendors, members of the academic community, and interested parties [Wikipedia 2006]. The standard has come a long way, paving the way for Native Queries, which are queries expressed programmatically. In February 2006, the ODMG has initiated efforts to develop new specifications based on the existing 3.0 standard.

Saving An Object To The Database

First we'll start with a simple business object. The classic Person class:

public class Person
{
    private string name;
    private int age;

    public Person( string personName )
    {
        name = personName;
    }

    public Person( string personName, int Age )
        : this( personName )
    {
        age = Age;
    }

    public string Name
    {
        get
        {
            return name;
        }
        
        set
        {
            name = value;
        }
    }

    public int Age
    {
        get
        {
            return age;
        }

        set
        {
            age = value;
        }
    }
}

Next, we'll write a simple data layer class to persist person objects:

public class DataLayer
    {
        private ObjectContainer m_DbConnection;

        public DataLayer( string DatabaseFile )
        {
            m_DbConnection = Db4oFactory.OpenFile( DatabaseFile );
        }

        public void Save( Person person )
        {
            this.m_DbConnection.Set( person );
            this.m_DbConnection.Commit();
        }

        public IList<Person> Get()
        {
            ObjectSet set = this.m_DbConnection.Get( typeof( Person ) );
            IList<Person> persons = new List<Person>();

            foreach ( Person p in set )
            {
                persons.Add( p );
            }

            return persons;
        }

        public void Close()
        {
            this.m_DbConnection.Close();
        }
    } 

Now we save person objects using our fresh data layer class:

DataLayer datalayer = new DataLayer( "sampleApp.yap" );
datalayer.Save( new Person( "Jon Smith", 25 ) ); 

A Native Query Example

One of the exciting features of db4o is its support for Native Queries using the new Predicate delegate object in the .NET 2.0 Framework. In case you forgot what Native Queries are, let's add some functionality to our DataLayer class to perform native queries to search for Person objects.

public class DataLayer
    {
        private ObjectContainer m_DbConnection;

        public DataLayer( string DatabaseFile )
        {
            m_DbConnection = Db4oFactory.OpenFile( DatabaseFile );
        }

        public void Save( Person person )
        {
            this.m_DbConnection.Set( person );
            this.m_DbConnection.Commit();
        }

        public IList<Person> Get()
        {
            ObjectSet set = this.m_DbConnection.Get( typeof( Person ) );
            IList<Person> persons = new List<Person>();

            foreach ( Person p in set )
            {
                persons.Add( p );
            }

            return persons;
        }

        public IList<Person> Get( Person templatePerson )
        {
            IList<Person> persons = m_DbConnection.Query<Person>
                    ( delegate( Person match )
            {
                return ( match.Name == templatePerson.Name ) | 
                    ( match.Age == templatePerson.Age );
            } );

            return persons;
        }

        public void Close()
        {
            this.m_DbConnection.Close();
        }
    } 

Now let's find some people:

DataLayer datalayer = new DataLayer( "sampleApp.yap" );
IList<person> persons = datalayer.Get( new Person( "Jon Smith" ) );

foreach( Person person in persons ){
  Console.Out.WriteLine( person.Name + " " + person.Age );
} 

The line...

return (match.Name == templatePerson.Name) | (match.Age == templatePerson.Age);

... is where the actual native query is performed. As you can see, a native query allows you to express search constraints in your native language (in this case, C#). This allows you to use what you know best to search for what you really need. You'll notice the use of a couple of new features in .NET 2.0 that are supported by the latest version of db4o - anonymous methods and the new Predicate generic delegate object, which allows you to pass in an anonymous method as a Predicate object instance, which is then used to determine whether the parameter passed into the anonymous method meets your needs. There are many more great uses for anonymous methods and the new generic delegate objects (like Predicate and Compare) which are beyond the scope of this article.

Object versus Relation Databases: How To Choose

Object databases are an exciting technology, with lots of potential. There are some things to consider before taking the plunge into your next project. Let's go over some caveats, and why you may want to choose a relational database rather than an object database.

Object databases are perfect for embedded deployments. This is due to an object database's true zero-administration nature, as well as a small footprint (for most vendor releases). Object databases also remove the need for OR mapping tools, and makes refactoring a breeze due to its tight integration with native languages.

Enterprise relational databases are normally deployed in client/server environments, with a running server serving out data to remote clients. While some object database vendors have client/server modes that can serve out data to remote clients, most object database solutions cannot perform with the same speed and robustness of enterprise RDBMS solutions when deployed in client/server mode. Another area to consider is Views. The relational model empowers a developer to provide different views of the same data. Views are not built into most ODMBS solutions. Other areas include foreign key constraints and check constraints (though most check constraints should start at your business layer).

The decision to use an ODBMS over an RDBMS is not an easy one, and should be carefully considered. Below are some general guidelines for choosing an object database:

• Embedded applications
• Complex object model, with deep object graphs that are not easily expressed using OR mapping tools and foreign key relationships
• Constantly changing data structures

Conclusion

In this article, we discussed the use of object databases in software projects. We covered some history regarding object databases, and went over a few programmatic examples in the C# language, as well a native query example. Finally, we discussed when to choose an object database over a relational database, and discussed why there are some caveats to choosing an object database.

History

• 13^th July, 2006: Initial post