Yes, I am looking at a database-centric application. I know that the
'larger' databases such as PostgreSQL, MySQL, etc. would not have any
problem handling that small amount of traffic.
My concern is that using postgres or mysql for this would be akin to
using a sledgehammer to swat a fly, when sqlite could most likely handle
the load well enough (I think) since the handful of people doing data
entry would rarely (if ever) be trying to write to the same record.
That would be the whole point of having multiple people doing data entry
in this situation - each one handling a different competitors entry form
or submitted scores.
My other reason for wanting one 'central' app is that there are various
functions (setting up the tournament, closing registration, editing
scores, finalizing results) that I really *don't* want the
satellite/client apps to be able to do. My personal view is that sort
of thing needs to be handled from one point, by one person (the match
director or chief stats officer, depending on the size of the event).
That is why I was looking at things in terms of having one central app
that handles the database, whether locally via sqlite or postgres or
whatever, but have the clients access go through that main application
in order to ensure that all they have is a limited set of CRUD abilities
for competitor registration and entering scores.
Thanks for the links... some of those I was already aware of (Camelot,
Dabo) but some of the others are new (QtAlchemy, etc). Should make for
interesting reading!
Thanks,
Monte
--
http://mail.python.org/mailman/listinfo/python-list
