Object database: Difference between revisions

Revision as of 16:36, 27 April 2004

Revision as of 01:35, 29 April 2004

Line 1:

[[de:Objektorientierte Datenbank]]

[[fr:Base de données orientée objet]]

An '''object database''' (more correctly referred to as ''ODBMS'' or ''OODBMS'' for ''Object Database Management System'') is a [[Database management system|DBMS]] that stores objects as opposed to [[row]]s/ or [[tuple]]s in respectively a RDBMSSQL or a RDBMS ([[relationalRelational databaseDatabase]] systemManagement System).

It is most often used in the case of [[C Plus Plus|C++]] and [[Java programming language|Java]] programmers that do not wish to deal with the [[impedance mismatch]] of going from an object oriented ([[OO]]) programming language to a database query language like [[SQL programming language]] that [[RDBMS]]is the current requirestandard. Developers prefer to be able to persist an object without having to go through a paradigm shift. Also missing from RDBMSSQL is the concept of [[polymorphism]], which is central to OO design, thus causing headaches when mapping from OO code to an RDBMSSQL.

Of course this has advantages and disadvantages. The ability to stay with an OO paradigm does great things for [[productivity]]. However, the RDBMSSQL modelDBMSs is a mature and proven one that has had decades of development and testing.

Certain benchmarks between ODBMS and RDBMSSQL DBMSs have shown that ODBMS can be clearly superior. One of the main reasons is that ODBMS do not use joins to associate objects but [[reference]]s which are usually implemented as [[pointer]]s. In the RDBMS modelSQL, a join would in most cases minimally require a search through a [[B-tree]] index. In general, navigation in an ODBMS is via traversing references, whereas in an RDBMSSQL data is joined in an ad-hoc fashion (which is better for arbitrary queries).

The successful market segments for ODBMS seem to be in [[telecommunication]]s, [[high energy physics]] and subsets of [[financial service]]s. The things that work against ODBMS seem to be the lack of [[interoperability]] with a great number of tools/features that are taken for granted in the RDBMSSQL world including but not limited to industry standard [[connectivity]], [[reporting]] tools, [[OLAP]] tools and [[backup]] and [[recovery]] standards. Additionally, ODBMS lacks a formal mathematical foundation, unlike the [[relational model]], which rests upon the firm and well-understood mathematical basis of the [[relational calculus]].

It must be noted that all SQL limitations come from it violating the principles of the [[relational model]]. A proper implementation, such as Alphora Dataphor, provides all the benefits of OO DBMSs without their drawbacks.

The [[Object Database Management Group]] did come up with a industry standard called [[ODMG]] 2.0 but it failed to gain acceptance with the ODBMS vendors mostly opting for proprietary features and extensions instead of attempting to grow the ODBMS pie by [[standards compliance]] and competing on implementations.

As an industry, ODBMS are a lost opportunity to revolutionize software development. Instead, there are more solutions out there providing wrongly so-called [[object-relational mapping]] abilities -- actually object-SQL mappings -- than there are ODBMS. There are many [[design pattern (computer science)|design pattern]]s for designing object-relationalSQL mappings (it is a non-trivial task; see notes to this effect in [[database]]).

==See also==