我目前正在使用 php、javascript 和 MySQL 设计一个 Web 应用程序。我正在考虑数据库的两种选择。
拥有所有锦标赛的主表，其中存储了基本信息以及锦标赛 ID。然后，我将创建分区、括号、比赛等表格，并将锦标赛 ID 附加到每个表格名称。然后在访问该锦标赛时，我会简单地执行类似“SELECT * FROM BRACKETS_[在此处插入锦标赛 ID]”的操作。
我的另一个选择是只使用通用括号、分区、比赛等表格，每条记录通过适当列中的外键链接到适当的锦标赛（或括号匹配、括号匹配等）。
我对第一种方法的担忧是，它对我来说有点太忙了，而且似乎数据库很快就会变得混乱。我对第二种方法的关注是性能。该程序有望在全国范围内（如果不是国际范围）具有影响力，而且我担心单个表中有这么多记录，并且可能有这么多人同时访问它，这可能会导致问题。
在数据库管理方面，我不是一个完整的新手。然而，这是我第一次完全独自完成，所以任何和所有的帮助都是值得的。谢谢！
不要为每个锦标赛创建表。表是实体的一种类型，而不是实体的实例。如果你混淆了这些概念，可维护性和可扩展性将是可怕的。你甚至自己这么说：
该程序有望在全国范围内（如果不是国际范围）具有影响力，而且我担心单个表中有这么多记录，并且可能有这么多人同时访问它，这可能会导致问题。
如果您需要为每条记录创建一个完整的表，您将如何扩展到该级别？
关于第二种方法的性能，您为什么担心？您是否有具体的指标来支持这些担忧？关系数据库往往非常擅长查询关系数据。所以保持你的数据是相关的。不要试图发挥创造力并破坏您正在使用的数据库技术的设计。
您已经命名了几种类型的实体：
这些听起来像我的桌子。根据您查询数据的方式来管理您的索引（也就是说，不要过度索引，否则您将通过插入/更新/删除来为它付费）。适当地规范化数据，取消规范化审计和报告更普遍的地方，等等。如果您担心性能，请密切关注查询执行路径，了解您访问数据的方式。轻微的调整可以产生很大的不同。
不要过早地优化。它在没有任何实际原因的情况下增加了复杂性。
首先，找到您需要存储的实体；诸如锦标赛、赛事、团队、竞争对手、奖品等。这些实体中的每一个都可能是桌子。
标准做法是为它们中的每一个设置一个主键。有时存在唯一标识行的列（或列组），因此您可以将其用作主键。但是，通常最好只使用一个名为ID或类似数字类型的列。RDBMS 为此类列创建和使用索引将更快、更容易。
将数据存储在它所属的位置：我希望在表中看到事件的日期和时间events，而不是在prizes表中。
另一个关键点是符合第一范式，因为这保证了数据的原子性。这很重要，因为它会在以后为您省去很多麻烦。通过正确执行此操作，您还将拥有正确数量的表格。
最后但同样重要的是：为查询中最常出现的列添加相关索引。这将对性能有很大帮助。不用担心表有太多行，如今 RDBMS-es 处理具有数亿行的表，它们旨在能够有效地做到这一点。
每当出现项目的新实例时创建新表的想法真的很糟糕，抱歉。
为什么这是一个坏主意的（肯定不完整）列表：
你说：
在数据库管理方面，我不是一个完整的新手。然而，这是我第一次完全独自完成......
您还记得另一个在需要新集合时克隆表的项目吗？如果是，您是否注意到这种方法存在一些问题？如果不是，您是否认为这正是 DBA 永远不会出于任何原因做的事情？
除了损害代码的质量和可维护性（正如其他人指出的那样），您是否真的会获得任何性能也是值得怀疑的。
当你执行...
SELECT * FROM BRACKETS_XXX
... DBMS 需要找到名称与“BRACKETS_XXX”匹配的表，并且该搜索是在 DBMS 的数据字典中完成的，该字典本身就是一堆表。因此，您正在将表中的搜索替换为数据字典表中的搜索。无论哪种方式，您都需要为搜索付出代价。
（字典表可能是也可能不是“真实”表，并且可能具有或可能不具有与真实表相似的性能特征，但我敢打赌，对于大量行，这些性能特征不太可能优于“普通”表。还有，数据字典的性能不太可能记录在案，你真的不应该依赖未记录的功能。）
此外，DBMS 会突然需要准备更多的 SQL 语句（因为它们现在是不同的语句，指的是不同的表），这会给性能带来额外的压力。