Hello. Another round of "have I got it right".

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.

OODB advantage: there is no impedance mismatch between the OODB and the
programming language - the OODB stores language objects.

OODB disadvantage: the OODB is oriented toward one and only one programming
language.

SQL advantage: there is a specified (and often documented) protocol between
a frontend and a backend; you 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.

SQL disadvantage: one always have 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.

SQL advantage: you have the full power of the relational algebra; there are
tables with normalized data and joins of all kinds.

SQL disadvantage: you have to understand at least the basics of the
relational algebra and rules of data normalization.

OODB advantage: you can directly manipulate with objects in you preferred
programming language.

OODB disadvantage: you have to manipulate with objects; for example, if you
need to select a subset you have to iterate over the entire set of objects.

SQL advantage: you can formally describe what subset of rows from what
Cartesian product you want to select.

SQL disadvantage: you have to formally describe what subset of rows from
what Cartesian product you want to select; you have to select a subset of
one row even if you know the direct ID of the row.

SQL disadvantage:  you are constrained by the set of data types and
functions the DBMS provides for you; 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.

Oleg.
--
     Oleg Broytmann            http://phd.pp.ru/            phd@phd.pp.ru
           Programmers don't die, they just GOSUB without RETURN.