[ Michael Watkins ]:
> A few comments - regarding relational, its ability to manage a huge volume of
> data is largely because of the facilities provided to add automatic indexes
> that span multiple keys. If you have a large table, unindexed, and do a
> sequential scan (retrieval) through every row to find matches for some
> criteria, its going to take more or less the same amount of time to do the
> same against a large set of objects in an OODB.

Perhaps, even in the absence of indexing, "select * from some_table" might
be faster than browsing for all instances of some class inside an OODB,
depending on the storage infrastructure choices that were made.
We need some benchmarks here.

> One advantage not mentioned with Relational that can't be dismissed easily is
> the preponderance of tools, and the facility by which integration with other
> applications - most running on some sort of SQL back end - can be made.

Indeed. Excellent point.

> Regarding OODB, is there anything truly in the OODB design that facilitates
> more easily textual content management? I don't think so. In my past I worked
> as a systems integrator implementing massive document and workflow management
> systems, all of them back ended with SQL. A big blob of text, or anything
> other big lump of information (as opposed to data), can be just as easily
> shoved into a SQL column as into an OODB as a python type, or, better yet in
> my opinion, into a darn file on the file system where it belongs.

One argument is creation of text-indexing structures (like suffix
or prefix  trees) being easier inside OODBs than RDBs, but that is
a question of practicality not feasibility.

> Back to the trivial, for ad hoc queries, I found, quite to my surprise, that
> its much easier in Python than in SQL, because after all I have the full
> power of the object and all its methods available to me, where in SQL all I
> have is SQL.

> Just think back to any hierarchical data structure modeled in SQL and
> how mind bending (for me at least) that is, compared to a hierarchy of
objects.

But the relational model is suitable for tabular data, not hierarchical, isn't
it ?
So it this argument fair ?

But I'm not trying to defend SQL against OODB, and neither the reverse.
Instead, I'll put some benchmarking in my TODO list. ;o)

best regards,
Senra