From an architectural design perspective, heres my comment..
I'd just stick with mysql.. its completely portable and lightweight, and it'll keep your support channels down. Go out to too many database systems and you'll end up with endless installation, configuration and support questions for a myrid of database systems. Just do yourself a favor and lock the database requirements.
I'd also consider trying to gear towards mysql 5 and writing as much as possible as stored procedures. The queries for the most part will be really simple, but doing them as stored procedures will make the queries alot easier to support (they'll be in a master mysql stored proc definition file versus scattered all throughout the code in inlined queries ) , and from a performance engineering perscpestive, it'll be ALOT easier to track down poorly performing database calls by using the server side performance timings and call frequencies that the database itself will generate. Needed optimizations will be alot easier to perform, as you'll have better metric data to decide what needs to be optimized.
Also, doing the calls as stored procedures, it'll make it easy for you to develop add on tools in other languages such as PHP (web interfaces/info sites) that exploit the exact same stored procedures to retrieve data without having to reinvent the data calls inside a different language. I know from experience that 20 different people developed 20 independent web tools and what not so there was a ton of code duplication in terms of the queries. Just make a set of stored procedures that handle all those requests and when new folks need new types of queries, just merge them into the SP base.
__________________
Quitters never win, and winners never quit, but those who never win and never quit are idiots.
|