MySQL：多个表还是一个包含许多列的表？

Question

因此，这更多是一个设计问题。我有一个主键（例如用户的ID），并且有大量与该用户相关联的信息。我应该根据信息将多个表细分为几类，还是只有一个表包含许多列？我过去这样做的方法是拥有多个表，例如，一个表用于应用程序使用情况数据，一个表用于配置文件信息，一个表用于后端令牌等，以使事情看起来井井有条。最近有人告诉我，最好不要那样做，有一个包含很多列的表也可以。关键是，所有这些列都具有相同的主键。我是数据库设计的新手，所以哪种方法更好，优缺点是什么？常规的做法是什么？

Answer 1

任何时候信息都是一对一的（每个用户都有一个用户名和密码），那么最好在一个表中使用它，因为它减少了数据库检索结果所需的联接数。我认为某些数据库对每个表的列数有限制，但是在正常情况下我不会担心它，如果需要，您可以随时将其拆分。

如果数据是一对多的（每个用户有数千行使用情况信息），则应将其拆分为单独的表以减少重复的数据（重复的数据会浪费存储空间，缓存空间，并使数据库难以维护）。

您可能会发现有关数据库规范化的Wikipedia文章很有趣，因为它深入讨论了这样做的原因：

数据库规范化是组织关系数据库的字段和表以最小化冗余和依赖性的过程。规范化通常涉及将大表划分为较小（和较少冗余）的表，并定义它们之间的关系。目的是隔离数据，以便可以仅在一个表中进行字段的添加，删除和修改，然后通过定义的关系传播到数据库的其余部分。

还需要注意非规范化，因为在某些情况下重复数据会更好（因为它减少了数据库读取数据时需要做的工作量）。我强烈建议您尽可能使数据规范化，以便开始使用，并且只有在您意识到特定查询中的性能问题时才进行非规范化。

Answer 2

一个大桌子通常是一个糟糕的选择。相关表是设计用于关系数据库的对象。如果您正确地建立索引并且知道如何编写性能查询，它们将表现良好。

当表中的列过多时，您可能会遇到数据库在其上存储信息的页面实际大小的问题。记录可能最终对于页面而言太大，从而可能导致您最终无法创建或更新特定记录而使用户不满意，或者您（至少在SQL Server中）可能因某些原因而溢出数据类型（如果要执行此操作，则需要查找一组规则），但是如果许多记录将使页面大小溢出，则会造成严重的性能问题。现在，MYSQL如何处理页面以及潜在页面大小过大时是否有问题，您需要在该数据库的文档中查找。

Answer 3

我有一个很好的例子。具有以下一组关系的过度标准化的数据库：

people -> rel_p2staff -> staff

和

people -> rel_p2prosp -> prospects

在人员具有姓名和人员详细信息的地方，人员仅具有人员记录的详细信息，潜在客户仅具有潜在客户的详细信息，而rel表是关系表，其中包含来自与人员和潜在人员链接的人员的外键。

这种设计针对整个数据库进行。

现在要查询这组关系，每次都是一个多表联接，有时是8个或更多表联接。到今年年中，它的运行情况一直很好，当时它开始变得非常缓慢，现在我们已经超过了40000条记录。

索引和所有低落的成果已于去年用完，所有查询都经过优化以达到完美。这是特定标准化设计的道路的尽头，现在，管理人员批准了对依赖于该应用程序的整个应用程序的重建以及数据库的重建，历时6个月。$$$$哎呀。

解决方案将是people -> staff与people -> prospect