/ Software / OODB

Object-oriented databases versus SQL databases

OODBs are based upon the object model - there are classes, objects, attributes. SQL DBMSes are based upon the relational algebra.

An OODB stores objects. An SQL DBMS stores tables (relations), rows and columns (attributes); data in columns are of simple types - string, integer, float, date/time, currency.

advantage disadvantage advantage disadvantage
    Well-known and popular technology. There are SQL standards; there are many implementations and tools of all kinds. Many different slightly or even not so slightly incompatible implementations; every implementation uses its own subset of the SQL standard, and extends it into its own direction.

There is no impedance mismatch between the OODB and the programming language - the OODB stores language objects.

The OODB is oriented toward one and only one programming language. Well, in theory it is possible to write serializers/deserializers in different languages, but in practice I don't know of any such interlanguage serializers.

There is a specified (and often documented) protocol between a frontend and a backend; one can write an implementation of the protocol in any programming language or link with client libraries. Thus a client can be written in any programming language - the server does not care until the FE/BE protocol is fullfiled.

One always has to go through FE/BE protocol, encode the queries one wants to pass to the server, decode the returned values and convert them to the programming language's data types.


One has the full power of the relational algebra; there are tables with normalized data and joins of all kinds.

One has to understand at least the basics of the relational algebra and rules of data normalization.

One can directly manipulate with objects in one's preferred programming language.

One has to manipulate with objects; for example, if one needs to select a subset one has to iterate over the entire set of objects. (This can be relived if the OODB has higher-level indexing.)

One can formally describe what subset of rows from what Cartesian product one wants to select.

One has to formally describe (in a language different from one's primary programming language) what subset of rows from what Cartesian product one wants to select.


Parallel access and concurrency control; table- and row-level locks; data consistency inside a transaction; serial (autoincremented) counters.

One is constrained by the set of data types and functions the DBMS provides; however rich the set is often insufficient, and SQL DBMSes seldom allow a user to extend it, and even if they allow - the language to write extensions is usually a different programming language, often proprietary and not portable among DBMSes.

OODBs can store deep hierarchies of objects and complex data types.


Hierarchical data can be stored in an SQL DB with different tricks, but well, they are just that - tricks and workarounds. SQL DBMSes certainly have problems with complex datatypes.

This is the page It was generated on Thu, 07 Sep 2017 20:05:55 GMT from CheetahTemplate OODB_vs_SQL.tmpl. Some rights are reserved. Read more about technical aspects of the site.