[Zope-DB] Re: firebird/interbase storage problem

Bernard Devlin bernard.devlin@knowledgeworks.plus.com
Tue, 14 May 2002 08:37:38 -0700


>>
ZODB File storage is very stable (I've never had any problems with it unlike
other databases I've used which sooner or later corrupt). However all
updates and inserts are ALWAYS appended to the end of the file so it grows
quickly and needs regular compaction.
<<
It is good to know that it should be so reliable and fast.  I know when I had problems restarting Zope I just copied the data.fs to a new install, and it all worked (with the exception of broken products, and I think it was one of the products [the Oracle connection, I think] that was stopping it from restarting.)

>>
It does by a factor of three or more.  I evaluated InterbaseStorage using
gvibDA some time ago.  It stores everything in text blobs (to do so it must
translate from binary to ascii for all database activity which is a huge hit
on performance) so any kind of searching is very slow.
<<
Does gvibDA also rely on kinterbasdb?  I mean, is this a problem with Interbase itself, or with the gvibDA, or with kinterbas?

>>
IMHO the way to use Zope is as a three tier app. 
<<

I agree in principle.  But isn't it better to store the business rules as much as possible in the SQL db at the backend?  And shouldn't one be using stored procedures as much as possible for the SQL rather than ZSQL, just to give greater separation?  This would give me more confidence that I am minimizing my dependence on any one component.

I could also start looking into the Python tools that enable one to utilise ZODB independently of Zope.  Once I get a better feel for how ZODB works, I'll have fewer concerns.

With regard to my replication concerns, I guess I can always start looking at rsynch...

Don't get me wrong... I think Zope is fantastic...I've been reviewing it with the competitive platforms for about 4 or 5 months.  It is going to be pivotal to my business plan...