tracking mass email MySQL design

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 pl开发者_开发技巧ease bombard me:))) Thanks

---

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.