[Zope] Problem: performance of retrieving properties from objects...

[Bill Anderson]

On Sat, 2002-04-06 at 02:31, Antwan Reijnen wrote:
> Hi Lennart!
> 
> Thanks for your prompt thoughts. Let me elaborate on some points:
> 
> 
> 
> >The depends entirely on what the data retrival methods are...
> 
> I use two methods: one 'official' one: propertysheet.propertyItems(), and one I wrote myself, which fetches the properties loop-wise with propertysheet.getProperty(id). The time they require, is roughly the same...

Is this done in a Script (Python)? or some other method in Zope? Are the
results expected to change often?  You may consider some caching.
Wouldn't help the first fetch, but would, however, help follow-on
requests.

Also, do you need *all* of them at once? Does the need for some of them
depend on certain variables? Of so, you may consider not getting the all
at once, but rathe ronly those that you need right then.


 
> > > 2) Suppose I have to switch to a database (there goes my weekend and free
> > > evenings next week). I want to retrieve the properties as one record then.
> >I
> > > think the number of 400 props will decrease in this matter, too.
> >
> >Why would they decrease just because you move them to a relational database?
> 
> Quite af few properties are 'lines' and 'selection / multiple selection'. I guess when I use a rdb some of this zope-specific properties won't be nessecary.

What do you mean by "Zope-Specific"?
 

...

> 
> 
> 
> >So a database would be faster here, since they
> >have a fixed data structure. On the other hand, you might get the same
> >effect by radically altering your data structure. Which brings us to the
> >main question:
> >
> >***Why on earth do you have 400 properties?***
> 
> Each sheet contains 13 questions with lots of answerfields.
> I already told my boss that these kinds of large questionaries will
> not work in practice (BORING), but... you know, he is the boss ;-)
> 

So, would I be correct in presuming you are building a questionnaire,
and using property sheets to store questions, and allowable answers
(i.e. in a multiple choice question)?

>From the limited info available, this sounds like a bad design choice,
no offense intended. For something like this, I would consider making
each questionnaire a container-like object and have the questions be
sub-objects. Then, if you are storing the answers, perhaps an object
that represents a completed questionnaire, that only stores the answers
given. I believe there are also a few Zope Products that do this as
well, you may consider looking into them.


-- 
Bill Anderson
Linux in Boise Club                  http://www.libc.org
Amateurs built the Ark, professionals built the Titanic.
Amateurs build Linux, professionals build Windows(tm).