Robert Cummings wrote:
On Thu, 2009-02-12 at 15:26 -0500, 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?
By writing this email you've already spent about as much time as it
would take to set up an SQL database and just start coding.
Cheers,
Rob.
True, but, the website is on a shared host which means someone must setup and
maintain the DB and my code has to create and remove tables, as needed. Plus,
someone must keep the login parms in sync between the DB and my code.
Al....
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
