Click here to Skip to main content
Click here to Skip to main content

Getting Started With Object Databases

By , 13 Jul 2006
Rate this:
Please Sign up or sign in to vote.

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

  • 13th July, 2006: Initial post

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

About the Author

carlos.muentes
Web Developer
United States United States
Carlos J. Muentes is an accomplished software engineer with over 11 years of experience building object oriented Desktop and Web applications using various programming languages and technologies on a number of platforms, with a current focus on C#, Java, and Python. Mr. Muentes is a specialist in C# and .NET technologies, having satisfactorily completed Microsoft developer certification exams, achieving Microsoft Certified Professional status.
 
Carlos is also heavily involved in HIE and HL7/CDA implementations. With a passion for HIE, he hopes to help transform the world, one electronic patient record at a time.

Comments and Discussions

 
QuestionQuery anomoly PinmemberMember 83593289-Nov-11 5:27 
GeneralThe Land of Milk and Honey PinmemberByteGhost13-Jul-06 15:43 
AnswerRe: The Land of Milk and Honey Pinmembermwdiablo13-Jul-06 16:09 
Your a bit confused.
if you have a GPL project then you can use the GPL license of db4o, but if you have a commercial product you need to get a Commercial license for db4o. No need to provide your source code if you have a commercial product, just purchase the dbo4 commercial license.
 
-----------------------------------------------------------------------------------------------------
Free General Public License
db4o is licensed under the GPL by default.
 
The GPL license is ideal if you plan to use db4o in house or you plan to develop and distribute your own derivative work as free software under the GPL as well.
 
Commercial License
A commercial license is required if you want to embed db4o in a commercial non-GPL product. Commercial licensees gain access to premium services and support.
-----------------------------------------------------------------------------------------------------
 
Just another rocket scientist, NOT!
GeneralRe: The Land of Milk and Honey PinmemberRavi Bhavnani14-Jul-06 2:38 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

| Advertise | Privacy | Mobile
Web02 | 2.8.140415.2 | Last Updated 13 Jul 2006
Article Copyright 2006 by carlos.muentes
Everything else Copyright © CodeProject, 1999-2014
Terms of Use
Layout: fixed | fluid