On Sat, 2008-03-22 at 04:55 -0400, Sean Allen wrote:
> On Mar 22, 2008, at 3:50 AM, Roché Compaan wrote:
> > On Fri, 2008-03-21 at 22:49 -0400, Sean Allen wrote:
> >> And we want to change the the description of Widget B and have that
> >> change appear for everything, how do I do that?
> >> basically, I want all LineItems for Widget A to all refer to a single
> >> instance of Product.
> > If you simply assign the product to an attribute on the line item, it
> > will create a reference in the ZODB. And you can use zc.relation to
> > index and query the relation.
> > # get the product from your products container:
> > product = productfolder['ProductXYZ']
> > # assign it to the line item instance
> > lineitem.product = product
> > It's really that simple! If you change the description attribute of
> > the
> > referenced product, all line items referencing it will show the new
> > description.
> Ha! Ok.
> Questions then from there.
> Why not store each object type,
> customer, order etc in their own folders?
You could, and I understand that you want to do so coming from a RDBMS
world, but if you are working with objects then you have the luxury of
organising content in a way that is closer to reality. I think it is
rather convenient to store a customer's orders inside it.
There is another good reason - it makes a lot more sense to distribute
object creation to different containers in the ZODB to avoid write
> is there a reason to have a folder that contains a more complete graph?
> what advantages would that have? speed of access?
What do you mean with "more complete graph"?
> the database i am looking at moving over has
> 1.2 million entries in a transactions table
> 980,000 orders
> 775,000 customers
> 1.5 million order items
I think these numbers are quite manageable. But think carefully what
kind of queries you want to do on the data. You have a very rich query
language in SQL that allows the construction of complex queries and it
will come naturally to you. To do the same in the ZODB will take careful
> and probably another 600,000 other assorted entires that would
> be needed in an oo scenario ( tons of join table entries get ditched
> tho, nice! )
> what type of server setup etc would be needed to handle that load
> considering that currently, 40,000 new orders go in a month
> along with the corresponding numbers of customers etc.
It depends a lot on the concurrency. It is usually advisable to not
compromise on server architecture, but be sure to get a server with
enough RAM (nothing less than 4GB) and very fast disks.
Upfront Systems http://www.upfrontsystems.co.za
For more information about ZODB, see the ZODB Wiki:
ZODB-Dev mailing list - ZODB-Dev@zope.org