On Oct 9, 2005, at 12:10 PM, Oleg Broytmann wrote:

> 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.

C.J. Date's "Database In Depth" gives an interesting description of
the relational model and how SQL falls short of the ideal.
Although he mocks OODBs, I still liked his book.

> 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.

True in practice, but you could use a language-neutral serialization
if you
really wanted to.  I'm sure you could load python pickles into some java
representation if it mattered.

> 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.

Importantly, you have the full power of your familiar programming
language
to operate on the objects.  Functions, variables, dictionaries, ... .

>
> 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.

No database can select an arbitrary subset based on the data without
examining
the data. In a traditional DB, we have the illusion that this happens
for free
because the client is more removed from the data.

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

Almost every "query" we actually need can be expressed as a list
comprehension.
More complicated variants, like GROUP BY are pretty easy to express
in in
a few lines or ordinary code.   The important thing, in my opinion,
is not that the
result can be described in a formal notation, but that it can be
described in
a way that minimizes the programmer's chance to misunderstand.
>
> 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.

That doesn't seem so bad.

>
> 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.

Ouch.