Objects forever

In my previous column, I looked at why object technology is becoming the de facto standard in terms of development practises. You may then be wondering about your data and database technology. Specifically, what will the impact of using an object-oriented (OO) development approach and language be with regard to your data?

Well, there is good news and bad news. The good news is that you can continue to use your relational database with OO languages. The bad news is that you will be neutralising much of the benefit of using an OO development approach if you simply stick to your existing relational database.

Why is this the case then? It comes down to a fundamentally different approach to systems development. The typical style of development used in conjunction with relational database is a data-centric approach where the data is analysed and the program written to access the data.

The OO approach looks first at the functionality required, and then at what objects and data are needed. This approach leads to programs structured around clusters of related objects. This is very different from the relational approach of organising data in tables with records that have the same structure but are otherwise unrelated.

The approach taken in object databases is to store objects in the program "as is" on the database, with all their related objects logically (sometimes physically) clustered. Access to the data is navigational, rather than search-based.

OK, so object databases store objects, but why should you care? If your development environment is object-oriented and you are using an RDMS then between 30% and 60% of the code your developers are writing is adding no business value. This code is written purely to map the data from your objects into tables and vice versa. This code normally requires your best programmers for a significant percentage of the project and is complex technical code. You will often find that a large proportion of your program defects can be traced to this technical mapping code.

So, your best developers are spending their days solving technical problems instead of solving the business problems. Why?

Simply, the impedance mismatch between relational databases and OO design needs to be overcome. It can be, but at a cost. To quote an analogy from Alistair Cockburn, author of "Surviving Object-Oriented Projects: A Managers Guide" (p73):

"You are parking your car in an object-oriented garage. You drive into the garage, get out, close the door and walk into your house. When you want to leave again, you walk into the garage, climb into the car, start it and drive away.

"You are parking your car in a relational garage. You drive into your garage, get out, take off the doors, put them onto the stack of doors; take off the wheels, put them onto the stack of wheels; take off the bumpers; and so on. You walk into your house. When you want to leave, you walk into the garage, take the doors off the stack, take the bumpers off the stack, take the wheels off the stack put them all onto the car`s frame, climb into the car, start it and drive away."

Putting relational data together is called joining. Joins are time-consuming. Fitting an OO design to a relational database calls for additional table joins and program code.

The answer to this question is surprisingly simple. YES!

Consider this: How many organisations are committing to Java? According to The GartnerGroup, by 2002, Java will be the dominant language, used in more than 60% of new development. Java is around five years old, yet it is fast becoming the language of choice.

Object databases have been around for more than 10 years and have enjoyed steady growth. This market is growing in excess of 40% per annum with the latest figures suggesting that this will be in excess of 60% for the current year.

Compare this to the relational database market where growth on a worldwide basis has been flat or negative in recent times. Clearly, this indicates a steady take up of object database technology as organisations start to see the benefits.

Since Java is being heavily used in developing Internet e-commerce applications, it should not come as a surprise that companies looking for 24x7 reliability and the performance to handle thousands of simultaneous users are turning to object databases. In many cases, the object databases are displacing relational databases since they provide superior performance for Internet-style applications.

Add to this the fact that about 4 out of 10 of your developers will become available again to do the real work that needs doing and you may begin to find it interesting.

So, who is using object databases: Dell computers (Europe), BEA Systems, Sun Microsystems, iMall (online shopping), Ericsson and MobileSoft (a division of Philips Electronics North America) to name but a few.

Object databases are not a silver bullet, nor will they always be able to replace your relational database. If your requirements include large numbers of ad-hoc queries and your applications have relatively uncomplicated data models, then you are probably better off sticking to your trusty RDBMS. For now!

If you are moving into e-commerce or are building new OO applications with highly complex data models, then an ODBMS is almost certainly better. In these types of applications they will provide superior performance, simpler code and eliminate a huge amount of mapping code that will need to be written.

Clearly, object databases will have an increasingly significant part to play in the future. They do not offer "plug-in" replacement for a relational database, nor is it likely that they ever will. Just as the market moved from ISAM and VSAM to relational, in time object databases will become the dominant style of database. Witness the number of RDBMS vendors who are scrambling to add some form of support for objects to their products.

One last cautionary note: Beware the RDBMS vendors who claim to support objects! If the data is ultimately stored in tables then it is not an object database. The database engine is simply performing some of the mapping for you. You will still pay the performance penalties that this implies.

In the same way that ISAM and RDBMS are different, so are RDBMS and ODBMS. If you need to store objects, seriously consider a true object database; do not be fooled by the marketing hype of the RDBMS vendors!

Object databases are enterprise-ready. Are you ready for them?