Question

我目前正在使用php，javascript和MySQL设计一个Web应用程序。我正在考虑数据库的两个选项。

拥有所有锦标赛的主表，其中存储了基本信息以及锦标赛ID。然后我会创建分区，括号，匹配等表，并在每个表名后附加锦标赛ID。然后在访问该锦标赛时，我会做一些类似“SELECT * FROM BRACKETS_ [在这里插入锦标赛]”的内容。

我的另一个选择是只使用通用括号，分区，匹配等表格，每个记录通过相应列中的外键链接到相应的锦标赛（或与括号，括号到分区等匹配）。

我对第一种方法的关注是，它对我来说有点过于繁琐，似乎数据库可能会很快变得混乱。我对第二种方法的关注是表现。希望这个项目有一个全国性的，如果不是国际性的，我关注的是单个表中的这么多记录，并且有很多人可能会同时点击它，这可能会导致问题。

在数据库管理方面，我不是一个完整的新手;然而，这是我完全独自完成的第一个，所以任何和所有的帮助都表示赞赏。谢谢！

Answer 1

不要为每个锦标赛创建表格。表是实体的类型，而不是实体的实例。如果你混淆这些概念，可维护性和可扩展性将是可怕的。你甚至自己这样说：

这个计划有望在全国范围内具有国家影响力，而且我关注的是一张桌子上有如此多的记录，并且有很多人可能会在同一时间点击它，这可能会导致问题。

如果您需要为每条记录创建一个完整的表格，您将如何扩展到该级别？

关于第二种方法的表现，您为何担心？您是否有特定的指标来支持这些问题？关系数据库往往非常善于查询关系数据。因此，请保持数据关系。不要试图发挥创意，破坏您正在使用的数据库技术的设计。

您已命名几种类型的实体：

这些对我来说就像桌子。根据您查询数据的方式管理索引（也就是说，不要过度索引，或者使用插入/更新/删除来为它付费）。适当地规范化数据，在审计和报告更普遍的地方进行去标准化等。如果您担心性能，请密切关注访问数据的方式的查询执行路径。轻微的调整可以产生很大的不同。

不要过早优化。它增加了复杂性而没有任何实际原因。

Answer 2

首先，找到您需要存储的实体;锦标赛，赛事，团队，竞争对手，奖品等等。每个实体都可能是表格。

标准做法是为每个人设置一个主键。有时会有唯一标识行的列（或列组），因此您可以将其用作主键。但是，通常最好只有一个名为ID的列或类似数字类型的列。 RDBMS为这些列创建和使用索引会更快更容易。

将数据存储在它所属的位置：我希望在events表中看到事件的日期和时间，而不是在prizes表中。

另一个关键点是符合First normal form，因为这确保了数据的原子性。这很重要，因为它可以在以后为您节省很多麻烦。通过正确执行此操作，您还将拥有正确数量的表。

最后但并非最不重要：将相关索引添加到查询中最常出现的列。这对性能有很大帮助。不要担心有太多行的表，RDBMS-es现在处理具有数亿行的表，它们的设计能够有效地完成。

Answer 3

每当项目的新实例出现时创建新表的想法都非常糟糕，抱歉。

一个（肯定不完整）列表，说明为什么这是一个坏主意：

你说：

在数据库管理方面，我不是一个完整的新手;然而，这是我完全独自完成的第一个......

你还能记得每当需要新的一套时克隆表的另一个项目吗？如果是，您是否注意到该方法存在一些问题？如果没有，您是否认为这正是DBA因任何原因从未做过的事情？

Answer 4

除了损害代码的质量和可维护性之外（正如其他人所指出的那样），你是否真的获得了任何性能也是值得怀疑的。

执行时......

SELECT * FROM BRACKETS_XXX

... DBMS需要找到名称与“BRACKETS_XXX”匹配的表，并且搜索是在DBMS'es数据字典中完成的，DBMS'es数据字典本身就是一堆表。因此，您将使用数据字典表中的搜索替换表中的搜索。你以任何一种方式支付搜索价格。

（字典表可能是也可能不是“真实”表，并且可能有也可能没有与真实表类似的性能特征，但我敢打赌，这些性能特征不一定比“普通”表更好。大行数。此外，数据字典的性能不太可能记录在案，您真的不应该依赖未记录的功能。）

此外，DBMS突然需要prepare更多的SQL语句（因为它们现在是不同的语句，指的是单独的表），这会对性能产生额外的压力。