On 26/09/2007, at 4:53 PM, André Warnier wrote:
Thanks for the answers so far, this is really the kind of stuff I
was hoping for. I appreciate even the 2-cent suggestions ;-), they
are not 2-cents to me.
Keep them coming.
About the MySQL suggestion : I have been thinking about the same
lines, specially since with DBI, it solves several issues at once.
My doubts in that respect have been that it would introduce one
more dependency (MySQL) in the application software in general.
That's the one drawback you'll run into, however...
The whole application package is multi-platform (Linux, various
Unixes, Win32) so any dependency can easily become a problem or an
installation hassle on one or the other platform. (That is for
instance one reason why I am not using one of the modules based on
Unix-like shared memory.)
MySQL is available on all these platforms, and considered stable as
well. Optionally you can use SQLite, which is also available for most
unixes and win32.
Also, doing this with an RDBMS also means defining and creating the
tables in advance to hold the data and so on, which is also an
additional initial setup burden.
Correct, however, if you design the tables beforehand, it's a single
step in the installation process that you'd have to do (i.e. cat
schema.sql|mysql ... etc.) -- it's up to you to decide whether the
drawbacks and extra work are worth the gains :)
So I do take note, but if anyone can think of other alternatives,
please keep posting.
Well, SQLite is one, if you want to keep things in memory you could
try loading the indexes into some hashes during server startup (at
least they'll be shared across servers), or load them during child
start. Drawback is that memory usage will go up a lot if your indexes
are big.
I think it may be better to start a separate thread for this
specific question about "sharing" such a table over many requests.
I think there's one already going but I haven't seen it yet.
Hope the info helps though :)
