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

Reply via email to