On Jun 1, 2007, at 6:07 AM, Kai Diefenbach wrote:
Stefan H. Holek <[EMAIL PROTECTED]> wrote:
Counting in the ZODB is more or less a no-go. You will get write
conflicts, and your ZODB will grow (too) quickly.
I kind of doubt that updating a little counter will make the database
grow "too" quickly, but that might depend on how often the counter
was updated and how you defined "too". :)
An issue with current ZODB storage implementations is that they
require explicit packing to remove old revisions and, in the case of
the file storage implementation, packing is rather expensive. (I
think the FileStorage pack implementation could be improved quite a
bit in this regard.) If you have a very busy counter, you might have
to pack more often then you otherwise would.
But what's an alternative?
That depends on the underlying use case. If you want to track
traffic, there's always log analysis. :)
In general I don't like the thought to use a RDBMS in parallel to
ZODB approach. And more than ever for a counter.
If the counter if updated a lot, then transactional databases,
including most RDBMSs and ZODB are likely to be too slow, again, for
some definition of "too".
Jim Fulton mailto:[EMAIL PROTECTED] Python
CTO (540) 361-1714
Zope Corporation http://www.zope.com http://www.zope.org
For more information about ZODB, see the ZODB Wiki:
ZODB-Dev mailing list - ZODB-Dev@zope.org