Re: Optimizing Queries in OODBs (was: Dreaming About Redesigning SQL)

"Mikito Harakiri" <mikharakiri_at_iahu.com> writes:

> "Patrick K. O'Brien" <pobrien_at_orbtech.com> wrote in message
> news:m265ixf4fe.fsf_at_orbtech.com...
> > lauri.pietarinen_at_atbusiness.com (Lauri Pietarinen) writes:
> > You wouldn't necessarily *have to*. PyPerSyst does not yet have a
> > declarative query capability. But if you add an index, the same
> > procedural code will now make use of that index (or rather, the
> > procedural code is calling methods of objects that are smart enough to
> > look for indexes to optimize themselves without requiring any changes
> > in application code).
> >
> > I only point this out becase critics of object databases really need
> > to improve their understanding of the capabilities of object languages
> > and object databases. They just aren't as inflexible as some pundits
> > would like to claim.
>
> I just went through simple stupidity test for Object Relational yesterday.
> Yes, Object Relational folks are not totally dumb, their stuff doesn't have
> *obvious* flaws. Therefore, yes it seems possible in principle to optimize
> queries in Object Extensions to SQL, and maybe in even OQL as well.
>
> The problem is that they raise complexity so significatly that it is
> extremely challenging for the optimizer to catch up. Note, that sql
> optimization is struggling to solve all problems in "simple" area of "flat"
> relations. Or, to put it in other words, how large is optimization team in
> your little PyPerSyst?

I don't completely understand all of what you have said, or exactly what you are asking, but I'll try to provide some information that may answer your question. First, PyPerSyst is not Relational, nor is it Object Relational, nor does it support OQL. It is a persistence system for Python objects. It can persist any Python object graph, but it also comes with a couple of base classes that can be used to create an object system that has some *qualities* in common with Relational databases.

As for optimization, that isn't quite as much of an issue, as PyPerSyst is an in-memory database, which means that all objects reside in RAM. Transactions are logged to disk before being executed, and the combination of system snapshot and transaction log is used to recover from a crash. So performance is good without a lot of attention to optimization.

There is no optimization team. As of right now, I have written all the PyPerSyst code. But I have drawn inspiration from other projects and academic papers, and there are several developers actively contributing ideas as well. PyPerSyst is free and open source, so you can examine the source code yourself:

http://sourceforge.net/projects/pypersyst/

Did that answer your question?

-- 
Patrick K. O'Brien
Orbtech      http://www.orbtech.com/web/pobrien
-----------------------------------------------
"Your source for Python programming expertise."
-----------------------------------------------