> > > > On top of that, if you are indexing the url string field (which I think > > would be reasonable if you had a lot of entries in the repository) then > the > > db will be rebuilding that index for each redundant url several times > > over... though this probably isn't as frequent an occurrence as a > "read", > > it will affect "insert new" and "move" operations. > > This is a good point. We are going to use slide as a CMS that will serve > and > compose web pages in real time, so read-performance is much more important > for us than write/copy/move-performance. If you are using slide as a > versioning system (to replace cvs or something like that) this might be > different. > So this is a point that should be discussed. >
Ah-ha, that does make sense. However... I am hoping to use Slide in a more "editorial" environment, where documents may composed from many "fragments" then published to the runtime environment (which is where I worry about runtime performance). These fragments may well be imported in quite large numbers (say between 10k and 50k at a time) and moved around a bit as people decide how they want to use them. This "bulk loading" and the editorial manipulation are where my concerns come from. Cheers Andy --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
