What is a Database?

We start off by talking about databases because it is important to understand what the purpose is for. A database is nothing more than a piece of software that sits on a computer solely designed to work with data in a structure manor.

At a high level, data is stored in one or more “tables”. A table is similar to that of an Excel Spreadsheet. It has rows and columns with addition of column names, the type of data stored and other meta data.

What is an Object Oriented Database?

Object Oriented Databases – otherwise known as Objectbases – are the next evolution of a database. Objectbases are similar to databases in that they store data. The main difference is how that data is stored and managed.

In databases, data is stored in a table structure. This table structure makes the interactions between the database and object oriented programs challenging.

In objectbases, we think of data in terms of objects. Rather than having 1 or more tables representing some real world entity we have a container of sorts that handles objects. These objects represent real world entities just like a database does except a database may require many tables to represent a table while an objectbase just needs one container.

Database vs. Objectbase

Lets put databases and objectbases head to head. This section will highlight pro’s and con’s from each side. Leaving us at a few conclusions.

Database Details

Let’s break down what today’s common databases have in common. Databases are comprised of the following constructs:

• Table – a construct made of columns and rows that contain data in a well defined format
• View – a construct which provides a filtered view of one or more tables
• Stored Procedure – a subroutine available to applications that access a relational database system
• User defined Function – subroutines similar to stored procedures except that they can be used within a query
• Query – bits of code written in a language called SQL that is designed with working with tabulated data or set(s)

These constructs are the pure basics of databases. So what is the problem with a database? At first glance, nothing. One would have to go from end to end during the development of a data driven application to fully understand the ramifications of this.

Our aim is to highlight the problem without that need.

70% of developer work consists of working with the database
This is an actual fact! That means that many developers creating data driven applications spend most of their time doing things that are considered “plumbing” to the application. Less time is spent on making the application do what it was meant to do!

Overtime object models and data models become detached and unmanageable
When a developer starts out everything is crisp and clean. Data models and object models almost mirror each other. They are perfect in a sense.

Down the road, the application begins to grow and morph based on business and/or technical demands. Changes in either the object model or data model often wind up rippling throughout the entire system. It becomes more complicated if multiple data drive applications use the same database.

Object / Table(s) Translations
Since real world entities are stored in one or more tables a translation is required to and from the database and the application. The database efficiently outputs tabulated data. Anything else becomes a large hindrance on the database server.

These translations needs maintenance and are error prone. So there is more work for the software developer.

Immediate Performance Gains
Databases are quick and simple to use – AT FIRST. Over time, they degrade with the changes and demands driven by business or technical requirements. Therefore, database developers find themselves creating indexes, optimizing queries in order to make things perform better.

Objectbase Details

Now let us move onto objectbases. Let’s break down what today’s current and future objectbase have or may have in common. Objectbases are comprised of the following constructs:

• Object Containers – a container storing objects representing real world entities (i.e. a Product)
• Object Relations – a container or construct used for relating objects together that are not already related through direct linkage

These constructs are the pure basics of objectbases. Pretty straight forward? Or are you more confused? These are high level conceptual constructs. There are a few objectbases on the market but none have gained the mainstream like traditional databases have. Bare with us as we explain further.

Developer Productivity
Developer’s can now focus on making software thinking about the purpose of the software rather than focusing on technical details that only make them drag their feet and skew project time lines.

No query language required
Developer’s no longer need to use another language in their tool box. Today’s data driven applications make developers use various languages forcing them to switch between mindsets constantly.

Their is no query language required with an objectbase. The query language is their object oriented language. Its the same language their applications are made in!

One Object Model to Rule the World
The model in the objectbase is the same as in the application(s). Therefore, there is never a difference between the two. Changes that are required may ripple similarly to a database. However, these changes can be easily refactored with today’s modern day integrated development environments (IDE’s) like MS Visual Studio.

No Translations
Objects are stored in containers in the objectbase. Therefore, there is no translation layer. Its completely banished from the objectbase. Its a straight pass through

Huge Performance Gains over Databases
Objectbases at first prove to be slower by nature when compared to databases. However, over time, objectbase performance significantly improves. So much that a standard database server cannot even compare to the metrics.