I’m currently designing a web application using php, javascript, and MySQL. I’m considering two options for the databases.
Having a master table for all the tournaments, with basic information stored there along with a tournament id. Then I would create divisions, brackets, matches, etc. tables with the tournament id appended to each table name. Then when accessing that tournament, I would simply do something like “SELECT * FROM BRACKETS_[insert tournamentID here]”.
My other option is to just have generic brackets, divisions, matches, etc. tables with each record being linked to the appropriate tournament, (or matches to brackets, brackets to divisions etc.) by a foreign key in the appropriate column.
My concern with the first approach is that it’s a bit too on the fly for me, and seems like the database could get messy very quickly. My concern with the second approach is performance. This program will hopefully have a national if not international reach, and I’m concerned with so many records in a single table, and with so many people possibly hitting it at the same time, it could cause problems.
I’m not a complete newb when it comes to database management; however, this is the first one I’ve done completely solo, so any and all help is appreciated. Thanks!
Do not create tables for each tournament. A table is a type of an entity, not an instance of an entity. Maintainability and scalability would be horrible if you mix up those concepts. You even say so yourself:
How on Earth would you scale to that level if you need to create a whole table for each record?
Regarding the performance of your second approach, why are you concerned? Do you have specific metrics to back up those concerns? Relational databases tend to be very good at querying relational data. So keep your data relational. Don’t try to be creative and undermine the design of the database technology you’re using.
You’ve named a few types of entities:
These sound like tables to me. Manage your indexes based on how you query the data (that is, don’t over-index or you’ll pay for it with inserts/updates/deletes). Normalize the data appropriately, de-normalize where audits and reporting are more prevalent, etc. If you’re worried about performance then keep an eye on the query execution paths for the ways in which you access the data. Slight tweaks can make a big difference.
Don’t pre-maturely optimize. It adds complexity without any actual reason.