I think the question comes up a lot because when you have a db that is non-relational, it's extremely difficult to get a handle on it's performance / reliability. With a relational database there are some standard benchmarks (granted the vendors manipulate these in various ways but you can get a fairly good idea of their general performance). The anecdotal, it's fast because I've seen it's fast is not quite as good as a standard test.
Most of the sql database vendors provide some means for managing the underlying files that actually store the data. Allowing me to add more, put them on separate partitions, etc. They also make it fairly easy to get the doc on how they layout the storage in these data files. They actually feature that in their development oriented doc -- to show how much better their technique is then other vendors.
To reduce the number of questions in this area, it seems like these two issues should be addressed.
Anecdotally :) --- I've become more comfortable with the Zope approach through usage and gathering the doc that is available in various places. Thanks for the feedback.
----- Original Message -----
From: seb bacon
Sent: Wednesday, July 04, 2001 2:17 PM
To: Steve Drees
Cc: Frank McGeough; Zope@Zope. Org
Subject: Re: [Zope] ZPhotoAlbum and images in general
* Steve Drees <drees@the-bridge.net> [010703 20:38]:
> > is storing everything in one big file makes me extremely nervous. Probably
> > doesn't matter for smaller web sites but if I actually wanted to use this
> > for larger sites it would be a real sticking point. Any advice on this
> > point?
>
> Most databases store everything in a few large files. Why is one large file
> worse?
> ZODB is a real database. It's a real good database.
I just had to chip in and repeat your point again just to emphasise
it, since this question comes up so much :-)
I would always use the ZODB FileStorage unless there was a very good
reason not to. It's fast, supports undos, is easy to back up, and
keeps all your application in one place. The only two good reasons,
not to do so are:
1) if your OS has a nastily small file size limit (e.g. pre-2.4
Linuxen)
2) If you need to access the same data from elsewhere
(e.g. membership data in an LDAP storage)
seb