详细信息表的效率如何？

Question

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

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

Answer 1

8-10详细行或8-10详细列？

如果它的行，那么你将混合苹果和橙子作为一对多的关系不能变成列。

如果是列，那么你正在谈论垂直分区。对于大型和非常大的表，将很少引用的列移动到Extra或Details表中（即将列垂直分区为“hot”和“cold”表）可以获得显着且事件上巨大的性能优势。较窄的表意味着每页数据密度更高，反过来意味着频繁查询所需的页面更少，IO更少，缓存效率更高，所有的优点都很好。

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

Answer 2

我在所有“依赖”上都使用Remus，但只是在为表/实体选择此设计后添加它，你必须还有一个很好的过程来确定什么是“标准” “以及实体的”细节“是什么。

错误放置一些应该是标准的细节可能是最糟糕的事情。因为您不需要存在行就像存在列一样容易（大复杂的触发器代码）。在行的类型上设置默认值是 lot 更难（大复杂约束代码）。索引也不容易（稀疏索引，可能？）。

将某些内容放错作为标准应该是一个细节，这不是一个错误，只是占用额外的行空间，并且可能无法有一个有意义的默认值。

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

作为一般规则，我不对每个实体表使用此模式，但只有具有某些要求和使用模式的实体表才能很好地适应此解决方案。

Answer 3

您的详细信息表是实体值表吗？在这种情况下，是的，你要求性能问题。

Answer 4

您正在混合使用两种不同的数据模型 - 一种是针对“标准”的域特定模型，另一种是针对“扩展”信息的键/值。

我不喜欢键/值表，除非绝对需要。它们与SQL数据库的概念背道而驰，通常表示试图将对象数据窃取到数据存储中，无法方便地处理它。

如果某些扩展信息通常为NULL，则可以将该列拆分为单独的表。但是，如果您对两个不同的列执行此操作，请将它们放在单独的表中，而不是同一个表中。

Answer 5

您所描述的是实体 - 属性 - 值设计。他们在世界上占有一席之地，但除非绝对必要，否则他们应该像瘟疫一样避免。我总是给出的类比是它们就像毒品一样：数量少，在特定情况下它们可能是有益的。太多会杀了你。它们的性能很差，不会扩展，因为它们都存储为字符串，所以你不会在值上获得任何类型的数据完整性。

所以，对你的问题的简短回答：如果你永远不需要查询特定的值，也不需要制作给定实体的属性的柱状报告，也不需要关心数据的完整性，也不需要做任何其他事情而不是吐出一大堆作为列表的实体数据，它们没问题。但是，如果你需要实际使用它们，那么你写的任何查询都不会有效。