As a DBA (soon ODBA when we have choosen the ODBMS), I need to
understand a bit more about the internal workings of ODBMS's.

1. How efficient are queries in ODBMS's? Given million of Person
objects, will a query like "firstname like 'Joe%' AND age < 50" be
answered quickly?

My next question is very related, I guess:

2. How does one index certain fields of an object, such as
'firstname'? I assume that's a requirement for efficient queries -
otherwise the DB will need to sequentially search gigabytes of data...

3. Schema change: how does one rename, add and delete fields of a
class? Also, what if the type change (i.e. from int to string)

4. Architecture: Is 2-tier or 3-tier preferred?

5. Given logical 3-tier... Physical topology: Should the business
logic object be placed on the same server as the ODBMS (to eliminate
network traffic), or on a separate server?

6. Does the ODBMS compress data before transmitting to and from the
server? I also wonder about how much data must be transmitted before
compression is worthwhile (since it makes the CPU's work harder)

7. Does any ODBMS's support partioning the database on several disks
on the same server to facilitate I/O parallellism?

8. Can I add users and users groups and perform authentication in most
ODBMS's?

9. For thousands of concurrent users, client caches seems like a
strange idea; too much network traffic seems to be generated when an
object is changed (and thousands of client caches must be updated,
right?). Can this be configured? Or have I misunderstood how the cache
works?

10. How are transactions performed? Multi-versioning? Exclusive
locking? Do the database lock the entire object graph, or just the
affected objects separately?

Any info on these points would be great!

"hantheman" <hantheman12 (AT) hotmail (DOT) com> wrote

I can give you my application development experience from working with
GemStone/S (with IBM's VisualAge Smalltalk). Other OODBs will do some
things differently.

The relational crowd will, no doubt, tell you why all my OODB experience is
crap. You decide.

The short answer is no... ad hoc queries like this don't fit well into an
OODB. But we have found it to be a non-issue. In an application, the vast
majority of queries are well known (vs. ad-hoc). So your "firstname like
'Joe%' AND age < 50" would be more like a 'candidatesLike:under: ' method on
a collection object, which has organized the data to make lookups by name
pattern and age fast. As you'd expect, if you then wanted to query by eye
colour, it would take longer. If, however, the eye colour query was used
frequently, you'd refactor the app to make it fast.

I work on a financial management app that does full end-to-end portfolio
management (analysis, risk management, trading, workflow, reports, ticket
generation, etc). We've replaced an RDB version, and we find that by using
an active OODB (like GemStone/S) and organizing our object model to fit the
business, our overall performance is much better and that ad hoc queries are
a non-issue.

A fundamental requirement in making this work is our willingness (and
ability) to refactor the application when the need arises. You can't use a
"it works so don't mess with it" attribute: since OODB hard code the most
common navigation paths, you have to be willing to change then as the
application changes. Using Smalltalk (in general) and GemStone/S (in
particular) makes this much easier.

That's an object model issue. If you need to access by first name patterns,
you'd create a first name indexed collection. We don't hold our objects in
large 'mother of all' collections. Instead we group objects by their
primary type: pooled fund vs. segragated fund vs. client portfolios. It
requires a solid understanding of the business domain and some solid OO
modeling skills.

In GemStone, each class structural change (instance variables, class
variables, etc) creates a new version of the class. Instances of a class
are then migrated from one version to the next. Data changes are handled
during this migration step (so if 'name' gets changed to 'firstName' and
'lastName', you'd write the migration script to parse the old name into the
new instance variables.

We use 2-tier. VAST & GemStone/S. Since GS is an active database, we don't
need another 'application server' layer, since the data is 'live' in
GemStone. We can trigger object methods either on the server or on the
client, using the exact same Smalltalk code. In fact, we build small
in-memory (no DB) models to develop new code and then push the updates into
the server. We can also dynamically change where methods are executed, so
that complex math on small sets can be done on the client, but large ones
can be done on the server. Very handy.

In GemStone it's one and the same.

Yup. GS has it as a built in option. And we've done some very cool work to
minimize large collection faulting between client and server. The
flexibility of our tool set is very good.

Yup... and I'd expect that to be true of most OODBs.


In GemStone there are very explicitly security tools that are user and group
based.

GemStone gives each user a consistent view of the object model. When the
user triggers an commit or abort this object model view is updated to the
most current version. A common technique is to trigger asynchronous aborts
for users that do not have pending changes and to keep update transactions
short.

The 'client caches' in GS are 'gem' process that run on either the server,
and 2nd 'gem server' or the client (you configure as required). It's these
gems that keep the 'client cache' and keep the end user applications object
state current. It's a well engineered solution.

GS offers both optimistic and pessimistic locking. We found that by keeping
transactions very short we're able to use optimistic locking virtually all
the time. Change conflicts are minimized by not using large collections (so
fewer users are hitting the same object). We can use selective locks on
high conflict objects (and we've implemented the code) but so far it has not
been an issue.

Again, this is a GemStone/S + VAST perspective. I'm sure there are other
tools and solutions.
I would, however, ignore anyone that says that one technology can work for
all applications. Anyone with broad real world experience knows that to be
false... use the right tool for the job, and educate yourself about the
tools that are available. Don't let marketing and herd mentalities govern
your decisions.

Good luck.
--
Bob Nemec
Northwater Objects