[ZODB-Dev] query the ZODB database

Christian Robottom Reis kiko@async.com.br
Mon, 2 Jul 2001 14:43:01 -0300 (BRT)


On Sat, 30 Jun 2001, Norman Khine wrote:

> having come from RDBMS background I would like to find out how to query the
> ZODB database.

In a very short, imprecise way, the answer is you don't. At least not in
the sense you imagine. The ZODB is in reality a persistence service, so it
only handles half of your RDBMS' attributions, which are storing data
_and_ querying them conveniently. The ZODB can store data, and it can
retreive data based on associations, but that is (roughly) all it does.

This means that _you_ will be providing the ways to query and summarize
data in the ZODB. IOW you have to define indexes or catalogs for your
collections of objects to be potentially queried.

> So, for an RDBMS application I have five related tables, something like
> "We have an employees table, code-related with departments and locations,
> which is also related to countries. The sales table has references to the
> employees and categories tables. Only employees belonging to the Sales
> department can be involved in sales, but they can sell anything, from
> software to services to education."

You won't be thinking of tables anymore. You'll need to think this out in
terms of classes and instances if you want to do it in an OO fashion.
You'll probably end up with five domain classes for your five tables, but
then you'll need extra index classes, and some sort of query classes to do
the actual index/catalog lookups.

I personally store my objects in BTrees provided separate from the ZODB.

> SELECT name, gender, location FROM locations INNER JOIN employees USING
> (loc_code);
>
> this will produce a table as:
>
> name 		gender 	location
> Luigi 	M 		Roma
> Mario 	M 		Roma
> Fred 		M 		Milano
> Cinzia 	F 		Cagliari
> ....

This is where I think the ZODB excels: to do this sort of query you'd
probably just follow references from your person instances. There is no
cross-index looking up for all but the most convoluted data schemas (at
which point it's usually time to pencil it out again).

> My question is: What are the equivalent python statements to produce the
> results from the above couple of examples, and what is the best way to
> design OO databases, would it be better to build a number of dictionaries to
> contain each specific type ie  for the different tables, if so what relates
> each table/dictionary to each other?

This isn't _my_ personal approach to OO database schema; I tend to think a
half-baked OO solution isn't worth a proper RDBMS solution (though others
might differ). You start out by modeling your domain classes, finding out
what is relation to what, and which of these need persistence. There's a
bit more planning involved (and it's not as familiar to most as E-R
modeling).

Take care,
--
/\/\ Christian Reis, Senior Engineer, Async Open Source, Brazil
~\/~ http://async.com.br/~kiko/ | [+55 16] 274 4311