Rene Veerman wrote:
Al wrote:
I'm scripting a light-weight, low volume signup registry for a running
club. Folks sign up to volunteer for events and the like. There will
generally be a handful of signup registries at any one time. A typical
registry will only contain 50 to 100 names. Each registry is only in
existence for a month or so.
I really don't see the advantage of using a real DB [e.g., mySQL,] for
this. Don't need any special searching, etc.
Am thinking of using a simple serialized array file for each registry;
or, using Pear Cache_lite. Cache_lite has several nice functions I
can take advantage of. In spite of its name, it can be configured to
be permanent.
I'd just go ahead and use Cache_lite; but, I'm always reluctant to use
a Pear package for fear it may not be updated for for future php
releases, etc. I aways aim to keep maintenance to a minimum.
Anyone had experience with Cache_Lite? Anyone have an opinion on the
alternatives or maybe another storage approach?
Thanks, Al........
AdoDB + SQL = easier to maintain than a half dozen custom storage
interfaces..
imo.
I don't really have any custom storage interfaces. To create a new signup
registry, we simply place a file in the topic directory [e.g.,
/10Krace/Volunteers.php] that contains one line of code that includes the
operational scripts.
require_once $_SERVER['DOCUMENT_ROOT'] . '/signups/commonReg.php';
commonReg.php takes care of everything and the signup's ID is simply
"/10Krace/Volunteers"
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
