多列好还是多表好？答案

【问题标题】：Is it better to have many columns, or many tables?多列好还是多表好？
【发布时间】：2014-05-29 17:29:56
【问题描述】：

想象一个假设的数据库，它存储产品。每个产品都有 100 个属性，尽管任何给定的产品只会为其中约 50 个属性设置值。我可以看到三种存储这些数据的方法：

100列的单表，
一个表很少（比如每个产品都有一个值的 10 列），另一个表有列（product_id、attribute、value）。即，EAV 数据存储。
每列都有一个单独的表。所以核心产品表可能有 2 列，另外还有 98 个其他表，每个表都有两列（product_id、value）。

撇开这些极端之间的灰色阴影，从纯粹的效率角度来看，哪个最好用？我假设它取决于正在运行的查询类型，即，如果大多数查询是针对产品的多个属性，还是针对多个产品的单个属性的值。这对效率有何影响？

假设这是一个使用 InnoDB 的 MySQL 数据库，并且所有表都有适当的外键，以及 product_id 上的索引。假设属性名称和值是字符串，并且没有索引。

一般来说，我问的是访问一个非常大的表是否比具有许多连接的查询花费更多或更少的时间。

我在这里发现了一个类似的问题：Best to have hundreds of columns or split into multiple tables?

不同之处在于，该问题询问的是特定情况，并没有真正告诉我一般情况下的效率。其他类似的问题都在说组织数据的最佳方式，我只是想知道不同的组织系统是如何影响查询速度的。

【问题讨论】：

Donald Knuth：过早的优化是万恶之源。
最有可能的折衷方案 - 有很多表格会更有效率，而有单个表格会更有效率。
您说，“我只是想知道不同的组织系统如何影响查询速度。”一般经验法则，涉及的表数越多，查询时间越长；因为数据库必须生成连接的结果。而如果它在一个表中，则关系已经定义。如果空间不是问题，并且您没有选择 * 从表中获取所有记录，则在大多数情况下，1 个表应该是最佳性能。不过也有例外。
@Barmar 热爱过早优化是万恶之源

标签： mysql database-design

【解决方案1】：

一般来说，我问的是访问一个非常大的表是否比具有许多连接的查询花费更多或更少的时间。

JOIN 会更慢。

然而，如果你通常只查询一个特定的列子集，而这个子集是"vertically partitioned"到它自己的单独表中，查询这样的“精益”表是通常比查询包含所有列的“胖”表要快。

但这是非常具体且脆弱（随着系统的发展而容易分裂）的情况，您应该在走这条路之前非常仔细地进行测试。您的默认起始位置应该是一张桌子。

【讨论】：

【解决方案2】：

一般来说，您拥有的表越多，您的设计就越规范化、更正确，从而更好（即：减少数据冗余）。

如果您后来发现在报告这些数据时遇到问题，那么可能是考虑创建非规范化值以改善任何特定性能问题的时候了。以后添加非规范化值比规范化现有设计不佳的数据库要痛苦得多。

在大多数情况下，EAV 是查询和维护的噩梦。

一个大纲设计是有一个产品表、一个属性表和一个包含相关条目的 ProductID 和 AttributeID 的 ProductAttributes 表。

【讨论】：

抱歉，这与标准化无关。
@BrankoDimitrijevic 是的。 “任何给定的产品只会为其中约 50 个设置值”。 QED
是的，但你事先不知道是哪个。

【解决方案3】：

正如您所提到的 - 它严格依赖于查询，这些查询将在这些数据上执行。如您所知，连接对数据库来说是个难题。我无法想象为简单的数据读取进行 50-60 次连接。在我的拙见中，这将是疯狂的。 :) 您可以做的最好的事情是引入测试数据并在 Management Studio 中以 Estimated Execution Plan 的形式在工具中检查您的特定查询。 MySQL 应该有类似的工具。

我倾向于建议您避免创建太多表格。我认为，它必须在未来引起问题。也许可以将很少使用的数据分类为单独的表或使用复杂类型？对于字符串数据，您可以尝试使用非聚集索引。

【讨论】：