明细表的效率如何？

Question

在我的工作中，我们有一个伪标准，创建一个表来保存实体的“标准”信息，另一个表，命名为'TableNameDetails'，它保存可选的数据元素。平均而言，对于主表中的每一行，大约有8-10个细节行。

我的问题是:将这些详细信息作为额外的可空列添加到主表上会产生什么样的性能影响？

Answer 1

您所描述的是实体-属性-值设计。他们在世界上有自己的位置，但除非绝对必要，否则应该像避免瘟疫一样避开他们。我总是给出一个类比，它们就像毒品:在少量和特定的情况下，它们可能是有益的。喝太多会要你的命。它们的性能将非常糟糕，并且无法伸缩，并且您将无法获得任何类型的值的数据完整性，因为它们都存储为字符串。

所以，对你的问题的简短回答是:如果你永远不需要查询特定值，也不需要为给定实体的属性生成列式报告，也不需要关心数据完整性，也不需要做任何事情，只需要将实体的整个数据以列表的形式输出，那么它们就很好。但是，如果您需要实际使用它们，那么您编写的任何查询都将是低效的。

Answer 2

8-10个明细行或8-10个明细列？

如果是行，那么您就是在混合使用苹果和橙子，因为一对多关系不能展平到列中。

如果是列，那么您就是在讨论垂直分区。对于大型和非常大型的表，将很少引用的列移动到额外的或详细的表中(即将列垂直划分为“热”表和“冷”表)可以带来显著的性能好处。更窄的表意味着更高的每页数据密度，反过来意味着更少的频繁查询所需的页，更少的IO，更好的缓存效率，所有的好处。

里程数可能会有所不同，这取决于“详细信息”列的平均宽度以及访问这些列的“很少”。

Answer 3

我同意Remus所有的“依赖”，但我只想补充说，在为表/实体选择这种设计后，你还必须有一个好的过程来确定什么是“标准”，什么是实体的“细节”。

把应该是标准的细节放错地方可能是最糟糕的事情。因为您不能像要求列存在那样容易地要求行存在(大型复杂的触发器代码)。在行类型上设置默认值是lot harder (大型复杂约束代码)。而且索引也不容易(也许是稀疏索引？)。

错误地将应该是细节的东西作为标准是不太错误的，只会占用额外的行空间，并且可能无法拥有有意义的默认值。

如果详细信息的结构非常弱，可以考虑对“详细信息”使用XML列，并且仍然可以使用XPath/XQuery查询它们。

作为一般规则，我不会对每个实体表都使用此模式，而是仅对具有特定需求和使用模式的实体表使用此模式，这些需求和使用模式非常适合此解决方案的优点。。