Ben van Staveren wrote: >> 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.
SQLite is a decent choice now that they have full text searching (thank Google). Swish-e is also cross platform with Windows binary builds available. One problem you can have with shipping a system that relies on someone else's mysql setup is that they may have it wrong. Or their settings may not be desireable for your application. A benefit of shipping your code with either SQLite (or Swish-e) built in is that you pick what works and you make sure that version/setting work with your application. If possible, I'd suggest adding a build system to your application that will build out the needed dependencies for you. Check out this thread on Perl Monks - http://perlmonks.org/?node_id=307399 >> 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 :) Right. You should already have an install process right? If you automate that as much as possible then it should just be one more step that you install script does. >> 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) Actually this is only true of non-threaded mpm's with an OS that supports Copy-On-Write memory (like prefork on Linux). I think it's also true of a threaded-mpm on any OS since it's a single Perl interpreter (am I right about this on Windows?). Preloading modules on prefork under an OS that doesn't do COW memory does not have any of that shared. -- Michael Peters Developer Plus Three, LP