For example, one of the most used queries in my app are for batched
lists. Say a user wants to see a list of customers. The default batch
size is to show 50 records at a time and the default sort is by
customer name. Currently the user has the ability to sort by any of
the columns in the batch list by simply clicking on the column title.
If I understand correctly, it means that I would have to load all 1MM
records into Squeak to sort them based on the user selection and then
jump ahead to whichever page the user was looking at and then show 50
records. As most everyone know, in the SQL world this is easily solved
by the SELECT * FROM * ORDER BY * OFFSET * LIMIT * command. I don't
know if OmniBase supports a more efficient way of doing this, or even
if the approach I mentioned is the most efficient one.

---

But this is the typical difference between an object oriented database
system and an object oriented storage management or persistency system
or however all these solutions are called - and you find these
problems in all object oriented languages (even in Java and C# :-)).

OODBMS (Versant, Objectivity or Gemstone) have indices like the
relational counterparts, which can speed up a query very much !!!

I always looked at persistency solutions and all I have to say is,
that I always went back to relational databases due to these problems
you mention.

---

No one mentioned Magma, which supports large, indexed collections
out-of-the-box.  It quickly and transparently pages to whatever
key-range of a LargeCollection you specify, and presents it in key
order.

While it, too, has very slow bulk-load performance, I hope to
alleviate that soon (I have been focusing on performance improvements
for the last month or two).

"These problems" are usually symptomatic of domain-models derived from
"thinking in tables."  Many corporate applications these days seem to
have a "spreadsheet" look-and-feel to them; lots and lots of tables of
"data" everywhere.

Where are the objects? A:  There aren't any, at least not as far as
the user is concerned.

For complex domain models, I believe a ODBMS will perform 10 - 100x
faster than a relational solution, not to mention the corresponding
reduction-factor in development time/effort.  For simple models with
just a few massive tables, relationals will be faster (maybe 2-3x).

---
There are lots of other problems concerning OODBMS system in real
daily life:

OODBMS (though not the older ones) are mainly language driven and they
work very well in the language they were intentionally written in/for.

Most of these "products" work therefore best with Java, C# and whatever

language is up to date - meaning, that Smalltalk is in general a 
language

not well supported in these cases.

Using Smalltalk I have to stress on the fact to produce open products 
and

this means for me: relational databases.

I've been involved in a project, where we choose an OODBMS (Versant) 
and

during this project the support fo Smalltalk was cancelled and in this
project I also saw, that the navigation approach (which is very often
stresses by OODBMS) is not a solution. Navigation is nothing more than
a special association - where even relational databases are very fast.

On the other hand I have also seen OODBMS systems, where the query
facilities are very weak. The indices facilities are weak and the
(very often file based) solutions are not crash prooven. (like
old dBase and Novell Netware - cut a connection and one has open
locks in the database ..)

RDBMS and Smalltalk works very well together - but of course the 
Smalltalker

has to accept the RDBMS and then you get perhaps not the best RDBMS 
design,

but a good working system - I love this.

Using RDBMS the system is open for all other languages.