I am (too) writing an mass email web based app. It is a concert organiser. I invite musical instrument players for each concert from a SQL DB and I need to track what happens with these people (mainly manual feeding:) then I want to send to them a rehearsal schedule and after the amount of money that I transfer to them.
So let's say I have 15 concerts a year and I invite 100-200 players for each concert and I want 80 / concert.
My SQL Design would be:
Contact details DB | Concert project DB | Tracking DB
DO you think a couple of years time the tracking would be too big to operate or how many record can I manage over the net without a noticeable increasing loading time. Or is there any better idea out there?
Anyone who has an idea please bombard me:))) Thanks
preguntado el 27 de agosto de 11 a las 21:08
At a rate of 5000 a year, it's gonna be smoking fast even if you host the database on your mobile phone, so don't lose any sleep over it. Even if you were to have something like 500,000 a year (so 100 time more), you'd end up with a DB holding 2.5 million records in 5 years, which is still not a huge amount that can be handled by a rather cheap server even today, let alone in 5 years.
So, whatever you go for, at your rate it will work out just fine, but if you feel like posting a detailed DB model I'm sure somebody will give you feedback on it. Just stop thinking a lot about optimizing and do the darn thing, you'll feel better.