Relational queries on zope obj db?
I'm very interested in using zope, but before I dive in, I have a fundamental question that always presents itself when looking at object database technologies. How does a zope developer select related items across folders from the object store? In effect, I'm asking what ZopeDB can do to feign relational SQL when it needs a select query on its objects, more extensive than a simple knock-out filter. The stumbling block is always the same: The problem domain may model perfectly in an ODB's folders/forms, but then the customer asks for the kind of report that would be a snap in SQL with any relational database, but is very difficult, or horrendously slow to do in the object database. A simple example would be: customer-class in one folder, purchaseorder-class in another, productitem-class in a third; select all purchase orders for customerA, displaying each individual productitem ordered. Thanks! If there's any way to do SQL-like queries against Zope's Object Database, or to arrive at the same result, I'm going to check out Zope very seriously.
From: "Jeff Kowalczyk" <jtk@adelphia.net>
A simple example would be: customer-class in one folder, purchaseorder-class in another, productitem-class in a third; select all purchase orders for customerA, displaying each individual productitem ordered.
Why would you have those three things in different folders? Why not, for example have: class Productitem: def __init___ price = 0 itemno = 0 upc = 0 description = '' etc.... class Purchaseorder: def __init__ ponumber = 0 itemlist = [] shipping = 0 terms = 'net 30' tax = 0 date = ZopeTime() def total(self) total = 0 for i in itemlist total = total + i.price total = total * (1 + self.tax) + self.shipping return total etc... def Customer: def __init__ customerid = 0 terms = 'net30' address = '' purchase_orders = [] etc.... So then you instantiate a customer object for each customer (customer1 = Customer()), and each time a purchase order is made you'd instantiate one of those and add it to the list: customer1.purchase_orders.append(Purchaseorder()) then you could add items to the last purchase order (of course, you'd probably want to address it by name, easily done in python, but for simplicity...) customer1.purchase_orders[-1].itemlist.append(Productitem()) Seems the object orientation of python makes something like this the natural organization, as opposed to the table orientation of a so-called RDB.... Then in Zope, you'd naturally take steps to Catalog these things as they were created, facilitating high speed searches and report generation.
Hello!
A simple example would be: customer-class in one folder, purchaseorder-class in another, productitem-class in a third; select all purchase orders for customerA, displaying each individual productitem ordered.
Why would you have those three things in different folders? Why not, for example have:
[... skipped ...]
Seems the object orientation of python makes something like this the natural organization, as opposed to the table orientation of a so-called RDB....
Then in Zope, you'd naturally take steps to Catalog these things as they were created, facilitating high speed searches and report generation.
Marc is right that most of the problems CAN be handled in an object-oriented way and using the catalog for indexing the rest. In fact, whenever you know in advance which queries you'll need, it should be no problem to model the object and indexing structure accordingly. But as soon as your customer asks for a new, cross-object query or just wants to be able to "dig in his data", SQL-based data storage is way more flexible, in some cases even the only viable solution. This is why the SmartObjects project (http://demo.iuveno-net.de/iuveno/Products/SmartObjects) exists. It aims at merging the two: Data stored in RDBMS tables should be usable as objects within Zope, but at the same time SQL queries should be possible. That's actually a bit of a simplification, as SmartObjects are supposed to also handle objects stored in LDAP or the filesystem, and even "composite" objects. But basically the issue you have would be tackled. If you are interested, just read the mailing list archives of SmartObjects and join the list ;-) Joachim
On Mon, May 28, 2001 at 09:56:01PM -0400, Jeff Kowalczyk wrote:
I'm very interested in using zope, but before I dive in, I have a fundamental question that always presents itself when looking at object database technologies.
How does a zope developer select related items across folders from the object store? In effect, I'm asking what ZopeDB can do to feign relational SQL when it needs a select query on its objects, more extensive than a simple knock-out filter.
The stumbling block is always the same: The problem domain may model perfectly in an ODB's folders/forms, but then the customer asks for the kind of report that would be a snap in SQL with any relational database, but is very difficult, or horrendously slow to do in the object database.
A simple example would be: customer-class in one folder, purchaseorder-class in another, productitem-class in a third; select all purchase orders for customerA, displaying each individual productitem ordered.
Thanks! If there's any way to do SQL-like queries against Zope's Object Database, or to arrive at the same result, I'm going to check out Zope very seriously.
And there is yet a third viewpoint. Smartobjects lets you delay choice. But if you know in advance that you are working with this kind of problem space, why use machinery to put off the ineveitable. Zope supports nearly 20 direct interfaces to relational databases (depending on how you count multiple interfaces to the same database). Included are postgresql, mysql, odbc, SAP, solid, oracle, sybase, ingres, informix and others. Working with a mainstream RDBMS should simply not be a problem. Jim Penny
_______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
participants (4)
-
Jeff Kowalczyk -
Jim Penny -
Joachim Werner -
marc lindahl