tedd wrote:
At 3:26 PM -0500 2/12/09, 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........
Personally, I find working with files more difficult than using a
database. Sure, the searching functions are an overkill for what you're
doing, but you don't have to use them either.
Think of a dB as just a filing system where you don't have to keep track
of paths.
Plus, at some future date, you may want people to logon to their
accounts and register for any events without having to fill in the forms
again and again with their name and address.
Make it easy for both you and your users.
Cheers,
tedd
Part of the problem is that in my attempt to keep my request brief, I skimped on
describing the big picture.
The site's architecture is highly compartmentalized into dozens of topics and
applications http://www.restonrunners.org. Each has it's own content managers,
who are not technical. I chose, early on, to use directories as a means to
control and maintain the compartmentalization. It has worked well; we can add,
change and remove whole topics with ease. It is easy for our content managers to
comprehend and work with. Applications like the one described here simply use a
calling file in the topic directory that consists of a single line of code.
require_once $_SERVER['DOCUMENT_ROOT'] . '/signups/commonReg.php'; commonReg.php
takes care of everything and the signup's ID is simply the /dir/callingFilename.
Signups are quite fluid, we have dozens per year and all have different fields.
One page has 9 individual signups and these will only be posted for less than 1
month. There is never any need for a common perpetual DB. There are no personal
accounts per se.
Thanks for everyones help in getting me to think about alternatives.
Al........
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
