[Zope] ZODB vs SQL, ZTables

[Jordan B. Baker]

On Mon, 7 Jun 1999, Michel Pelletier wrote:

> > 1) Would I be re-inventing the wheel here?  Can ZTables instantiate
> > ZClasses?  The reason I like the ZClasses is because I'd like 
> > to write my
> > business logic in Python.  I suppose I could do this with External
> > methods.
> 
> ZTables return an result 'object' called a 'brain'.  This object is
> instanciated on the fly when you make queries.  If you define your own
> type of brain, then you can have your own types of objects.  I don't see
> any reason why this object couldn't be a ZClass, but currently there is
> no mechanism to hook the two together through the ZClass, there would
> have to be some python involved.

This is pretty intriguing.  I need to consider the cost/benefits.

One thing I don't like about this is that (I assume) you can't change the
data in the ZTable simply by assigning attributes as you could if each
piece of data was stored as objects.

Either way it would be fairly easy to write getter/setter methods that
would use a ZTables API to update the records.  I assume this would work
anyway.

> > 2) I realize the indexing system isn't well documented at > this
> point, but > if you can figure out the system is it usable? :) >
> 
> It's very usable.  I'm working on some documentation for it right now,
> but it might be lower level than you think.  What you might want to wait
> for is the Catalog, whose purpose is to do exactly what you want,
> catalog and index Zope objects.

Well, I'd certainly be willing to provide feedback on the documentation as
this would give me an idea of how it works at a lower level.  And it means
I could start protyping some of my ideas today instead of waiting for the
internal QA of the Catalog to move along.

> > I'm just struggling a bit with the concepts of going 
> > completely OO instead
> > of storing my data in a SQL database.
> 
> There are benefits to using SQL, and there are benefits to using
> objects.  You have to weigh these things when elaborating your design.
> if you think your system is very object oriented, or very relational, or
> a hybrid of the two.

Yes, thanks for pointing that out.  I do find that certain data structures
are a pain to implement in SQL.  Ie, when you want an ordered list of
items.

Certain factors are pointing towards using the object database here.  
Main one is the portability and flexibility.  Using ZClasses is nicer
still because I'd like to provide a seperate property sheet for users to
customize each object if they like.

> The catalog is designed to do almost exactly what your looking for.  
> It's unclear at the moment what exactly will get open sourced as a the
> 'catalog' since the catalog consists of several layers of components
> at the moment. Chances are there will be no managment interface (maybe
> a minimal one), just a DTML API which you can use to search or
> manipulate the catalog.

Hmm, probably that's about all I'd need anyway.

If there is any alpha testing going with it I'd be willing to run it
through its paces.  Otherwise roughly when do you think Catalog will be
available in some form?

> -Michel

Thanks for the great info. I'll chew on this a bit. :)

-------
Jordan B. Baker -- jbb@spyderlab.com
weaving the web @ http://www.spyderlab.com