The Current State of Database Technologies

In the beginning…

… there were databases. Pretty much every developer has at one point or another used a database to store data. The data in a traditional relational database is categorized according to particular schemas or tables. This allows the data to be saved, retrieved, updated and deleted in an orderly fashion, usually by multiple individuals connecting from a variety of sources by using the widely known Structured Query Language (SQL).

- Advertisement -

This model worked well for a long time, but it was not without problems. One of the larger problems was that the internal representation of the data in the application code tended not to be very well correlated to the schemas – causing application developers to have to perform various acrobatic stunts in order to retrieve data efficiently.

The Evolution of Programming Languages:

As time went on, the Object Oriented paradigm became the de-facto standard for programming. This ushered in the era of the object. Objects were very good at promoting abstraction of the system – now programmers could speak of the object as the thing without the need to include all of its methods and attributes.

It was only a matter of time before they wanted to be able to store these objects directly without having to break the object into its constituent parts in order to do so.
Early attempts divided the system into tiers (n-tier model) with the simplest of these – the 3-tier model comprises a presentation layer, an application layer and a data layer. This data layer often consisted of a set of application codes which was responsible for translating objects into their related database columns.

This worked well – especially for smaller systems, but a lot of developer time was then consumed with having to maintain the data tier. This was not a very good use of application developers’ time, and it was not long before another solution was sought.

- Advertisement -

Enter Object Prevalence:

The term object prevalence rapidly grew out of the need to save the state of an object quickly, easily and in a way that was easily retrievable by the application language. Early object prevalence layers encountered many of the difficulties which had already been solved by relational databases – the need for atomicity, consistency, isolation and durability (ACID test) as well as redundancy and transaction support.

Prevalence layers typically store the objects in memory and soon encountered another problem – RAM was not quite as plentiful as hard disk space, nor as cheap. This made prevalence layers impractical for situations where very large amounts of data had to be stored and retrieved by and from multiple sources, and all but relegated its use to situations where the number of objects was very small.

Next up Object Relational Mapping:

As a balance between pure object persistence and having to break objects up in order to store them in traditional relational databases – we have got ORM. Since businesses had invested heavily in relational database technology, it didn’t make sense to abandon them. Instead, by using ORM, it was possible to reduce the development effort required for the traditional system while building upon infrastructure that was heavily invested in and costly to change.

ORM essentially automated the data tier of the traditional 3-tier model. By providing general interfaces to create objects, store, retrieve, update and delete the object’s attributes – ORM freed the developer from having to code these functions for each object.

The Alternative – Object Purity:

While ORM and object prevalence layers were being developed, some took a different approach. They began developing pure object databases which would store application language objects directly.

Object databases allow application developers to focus on their job – application development – without worrying about the details of interfacing with the database.

There has been a fair amount of discussion and argument on which technology is better, however, it is important to recognize that each alternative comes with its own strengths, weaknesses and cost of implementation. Hopefully, the decision of which technology to use in your particular situation will become more apparent after research.

- Advertisement -