bet at rahul.net
Wed Nov 24 11:32:30 PST 2004
Whew. Never heard of precisely that application before.
Of course, if there's an already-written solution, that's surely the
best place to start.
If not, then I'd sketch out the shape of a solution. I'll describe
in terms of the tools I've used and that I like, other folks will
have other favourites.
The heart of the design is an RDBMS. Usually I avoid 'em like the
plague, but this app has one of the characteristics that justify
'em: multiple users updating data, which must be kept consistent.
I like MySQL, so at this point I'd be starting the process of
getting a package I liked installed and configured on a platform I
liked. If you pick a different RDBMS, go ahead and start providing
it from the beginning, this can proceed in parallel with the rest of
You'll need to keep some data. Unless you happen to have a database
professional handy, I wouldn't worry too much about the fiddly bits
of database schema design. Envision your data organized as a series
of tables. Don't put the same column in two different tables,
duplicating data, with one exception: key columns. These need to be
"unique", two different records can't have the same key, and they're
used to join tables. If your records don't have natural key columns,
no problem, RDBMSes can generate keys easily, simple sequence
numbers. This step is the part of the design to take time on, to get
right; if this is broke the rest will be a real pain. So figure out
what data you want and how it organizes into tables. If you run into
a puzzle you can probably find places to ask for help:-).
Once you've got your tables designed, you're nearly done. Set up the
RDMS with these tables. If you've got any existing backlog of data,
format it into these tables and load it into the database. Make sure
you can repeat this trick; during the final dev phase, users will be
testing the user interfaces with your static copy of the backlog
data, but real work will be proceding outside, so you'll need to
update or rebuild the database before your new app can go prod.
Now is the time to do user interfaces. What classes of users do you
have, organized by the different jobs they need to do? I like
crafting a completely separate user interface for each class of
user, each tuned to just their needs.
I like building them in plain, portable HTML under a web server. I'd
prototype with perl, using the CGI, DBI, and DBD::mysql modules. I'd
use mini_httpd as the webserver, too. Others would certainly choose
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
More information about the lfs-chat