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

Question

所以这更像是一个设计问题。

我有一个主键（比如用户的ID），我有大量与该用户相关的信息。

我是否应该根据信息将多个表分解为类别，或者我应该只有一个包含多列的表？

我以前的方式是拥有多个表，例如，一个表用于应用程序使用数据，一个表用于配置文件信息，一个表用于后端令牌等，以使事情看起来井井有条。

最近有人告诉我，最好不要这样做，并且拥有一个包含大量列的表是可以的。问题是，所有这些列都具有相同的主键。

我对数据库设计很陌生，所以哪种方法更好，哪些优点和缺点？

传统的做法是什么？

Answer 1

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

如果数据是一对多（每个用户有数千行的使用信息），那么它应该被拆分成单独的表以减少重复数据（重复数据浪费存储空间，缓存空间，并使数据库更难维护。）

您可能会发现database normalization上的维基百科文章很有趣，因为它深入讨论了这个原因：

  

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

Denormalization也需要注意，因为有些情况下重复数据更好（因为它减少了数据库在读取数据时需要完成的工作量）。我强烈建议您尽可能将数据标准化，并且只有在了解特定查询中的性能问题时才进行非规范化。

Answer 2

一张大桌往往是一个糟糕的选择。相关表是关系数据库的设计用途。如果您正确索引并知道如何编写高性能查询，那么它们将表现良好。

当表格列太多时，您可能会遇到数据库存储信息的页面实际大小的问题。记录最终可能对于页面来说太大，在这种情况下，您可能最终无法创建或更新使用户不满意的特定记录，或者您可能（至少在SQL Server中）允许某些特定溢出数据类型（如果您正在执行此操作，则需要查看一组规则）但如果许多记录将溢出页面大小，则可能会产生棘手的性能问题。现在，MYSQL如何处理页面以及当潜在页面大小过大时是否有问题是您必须在该数据库的文档中查找的内容。

Answer 3

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

people -> rel_p2staff -> staff

和

people -> rel_p2prosp -> prospects

如果人们有姓名和人员详细信息，工作人员只有员工记录详细信息，前景只有潜在客户详细信息，而rel表是与人员和潜在客户链接的外键关系表。

这种设计继续用于整个数据库。

现在要查询这组关系，每次都是一个多表连接，有时候会加入8个表。它已经在今年年中很好地工作，当它开始变得非常缓慢，因为我们已经超过40000人的记录。

索引和所有低悬的果实去年已用完，所有查询都经过优化以达到完美。这是特定规范化设计和管理的道路的终点，现在批准了整个应用程序的重建，该应用程序依赖于它以及数据库的重组，为期6个月。 $$$$哎哟。

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

建立直接关系

Answer 4

对此很了解，作为一个经常使用MySQL的人，最近又切换到Postgres，最大的优点之一是可以将JSON对象添加到Postgres中的字段。

因此，如果您处于这种情况，则不必一定要在一个包含许多列的大表之间进行拆分，但是可以将列合并到JSON对象中以减少它，例如地址不是5列，而只能是1列。您也可以查询该对象。

Answer 5

如果你把所有东西都放在一个表中，你会问自己这些问题吗，你会为这个用户多行吗？如果必须更新用户，是否要保留审计跟踪？用户可以拥有多个数据元素实例吗？ （比如电话号码）您是否会想要稍后添加元素或元素集？  如果您回答是，则很可能您希望拥有具有外键关系的子表。

父/子表的优点是数据完整性，通过索引的性能（是的，您也可以在平面表上执行），如果您以后需要添加字段，IMO更容易维护，特别是如果它是必填字段。

缺点设计更难，查询变得稍微复杂

但是，在很多情况下，一个大的平台是合适的，所以你必须看看你的情况来决定。

Answer 6

我已经完成了某种数据库设计。对我来说，这取决于系统与数据库管理的难度;是的，只在一个地方拥有独特的数据是真的，但是对于具有大量记录的过度规范化的数据库来说真的很难进行查询。只需结合两个架构;如果你觉得你将拥有像facebook，gmail等那样难以维护的大量记录，请使用一张巨大的桌子。并使用不同的表作为简单系统的一组记录...这只是我的意见..我希望它可以帮助..只是这样做..你可以做到...... :)

Answer 7

执行此操作的传统方法是使用星型模式或雪花模式中的不同表。 Howeevr，我将这个策略基于两倍。我相信数据应该只存在于一个地方的理论，因为我提到的模式运作良好。但是，我也相信，对于报告引擎和BI套件，柱状方法将非常有益，因为它更能支持报告需求。像infobright.org那样的柱状方法具有巨大的性能提升和压缩，这使得使用这两种方法非常有用。很多公司开始意识到组织中只有一个数据库架构并不能满足他们的全部需求。很多公司都在实施拥有多个数据库架构的概念。

Answer 8

我认为拥有一个表更有效但是你应该确保表的组织方式能够显示同一行的关系，趋势以及变量的差异。 例如，如果表格显示了学生的年龄和成绩，那么您应该以一种方式对表格进行排序，使得最高分的人与最低分的分数很好地区分，并且学生的年龄差异是均匀的。