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

Question

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

我有一个主键(比如用户的ID),我有大量与该用户相关的信息.

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

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

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

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

这样做的传统方式是什么？

Answer 1

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

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

您可能会发现维基百科关于数据库规范化的文章很有趣,因为它深入讨论了这个原因:

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

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

Answer 2

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

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

Answer 3

遇到这个问题，作为一个曾经经常使用 MySQL，然后最近切换到 Postgres 的人，最大的优点之一是您可以将 JSON 对象添加到 Postgres 中的字段中。

因此，如果您处于这种情况，您不必在一个包含许多列的大表之间做出决定并将其拆分，但您可以将列合并到 JSON 对象中以减少它，例如，地址不是 5 列，它可以成为一体。您也可以查询该对象。

Answer 4

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

people -> rel_p2staff -> staff

和

people -> rel_p2prosp -> prospects

其中人员具有姓名和人员详细信息，员工仅具有员工记录详细信息，潜在客户仅具有潜在客户详细信息，rel 表是具有链接到员工和潜在客户的人员的外键的关系表。

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

现在要查询这组关系，每次都是多表连接，有时是 8 个甚至更多表连接。直到今年年中，它一直运行良好，但由于我们超过了 40000 条人员记录，它开始变得非常缓慢。

索引和所有容易实现的目标已于去年用完，所有查询都已优化至完美。这是特定规范化设计之路的终点，管理人员现已批准在 6 个月的期限内重建依赖于它的整个应用程序以及数据库的重组。$$$$ 哎呀。

people -> staff解决方案是与和建立直接关系people -> prospect