你将如何实现一个非常宽的“表”？答案

【问题标题】：How would you implement a very wide "table"?你将如何实现一个非常宽的“表”？
【发布时间】：2011-03-24 23:28:03
【问题描述】：

假设您正在为一个具有许多属性 (2400+) 的实体建模，远大于给定数据库引擎的物理限制（例如 ~1000 SQL Server）。除了域/候选键之外，您对这些数据点的相对重要性（哪些是热门/最常使用的）一无所知，您将如何实现它？

A) EAV。（嘘......原生关系工具被抛出窗外。）

B) 直接穿过。第一个表有一个主键和 1000 列，直到上限。下一个表是 1000，外键到第一个。最后一个表是剩下的 400 个，也是外键的。

C) 在ceil( n / limit ) 表中均匀分布。每个表都有偶数列，第一个表的外键。 800、800、800。

D) 别的……

为什么？

编辑：这更像是一个哲学/通用问题，与任何特定限制或引擎无关。

Edit^2：正如许多人指出的那样，数据可能没有标准化。按照惯例，当时的业务限制使深入研究成为不可能。

【问题讨论】：

它警告我这是一个见仁见智的问题。呃，我不知道。
是的，当我看到您的编辑时，我删除了“为什么 CW”查询！

标签： sql sql-server database

【解决方案1】：

我的解决方案：进一步调查。具体来说，确定表是否真正规范化（在 2400 列这似乎不太可能）。

如果没有，则重新构建，直到完全规范化（此时每个表的列可能少于 1000 列）。

如果它已经完全标准化，则为每个属性建立（尽可能）近似的总体频率。将最常出现的属性放在实体的“主”表上，使用 2 或 3 个额外的表来放置不常填充的属性。（尝试将出现频率作为确定哪些字段应该出现在哪些表上的标准。）

只考虑 EAV 用于极其稀疏的属性（最好，根本不考虑）。

【讨论】：

不同方法的完美平衡！

【解决方案2】：

我想使用垂直（增加行数）方法而不是水平（增加列数）。

你可以试试这种方法

表 -- id ，property_name -- property_value。

方法的优点是，在引入新属性/列时无需更改/创建表。

【讨论】：

这也是我提出的完全相同的答案。

【解决方案3】：

使用Sparse Columns 最多可显示 30000 列。与 EAV 或 XML 相比，最大的优势在于您可以将 Filtered Indexes 与稀疏列结合使用，从而非常有效地搜索常见属性。

【讨论】：

【解决方案4】：

我会经常查看数据模型更仔细。 3号正常吗形式？是否有属性组应该在逻辑上分组一起放到他们自己的表中？
假设它是标准化的并且实体确实有2400+属性，我不会那么快嘘 EAV model。恕我直言，这是最好的，最灵活的解决方案你描述的情况。它为您提供对稀疏数据的内置支持，并为您提供良好的搜索速度，因为任何给定属性的值都可以在单个索引中找到。

【讨论】：

【解决方案5】：

对我来说关键是这件作品：

对这些数据点的相对重要性一无所知（哪些是最热门/最常用的）

如果您知道哪些字段更重要，我会将这些更重要的字段放在“本机”表中，并让 EAV 结构处理其余部分。

问题是，如果没有这些信息，无论如何你真的是瞎了眼。无论您有 2400 个字段还是只有 24 个字段，您都应该对数据点的含义（以及因此的相对重要性，或至少是逻辑分组）有所了解。

【讨论】：

【解决方案6】：

我会使用带有实体外键的一对多属性表。

例如

实体：id，

属性：id、entity_id、attr_name、值

添加

或者正如Butler Lampson 所说，“计算机科学中的所有问题都可以通过另一个间接级别来解决”

【讨论】：

【解决方案7】：

我会旋转列并使它们成为行。您可以将其作为 fkey 返回到包含所有可能属性列表的查找表，而不是将包含属性名称的列作为字符串 (nvarchar)。

以这种方式旋转它意味着你：

不要有大量表格来记录一项的详细信息
没有超宽的桌子
您可以仅存储由于轮换而需要的信息（如果您不想存储特定属性，则不要存储该行）

【讨论】：

不过，这仍然是 EAV 变体

【解决方案8】：

在没有太多这方面的知识的情况下，我认为具有这么多属性的实体确实需要重新设计。我的意思是把大的东西分成逻辑连接的小部分。

【讨论】：

那将是理想的，但考虑到时间限制（当时），花时间研究“最终正确”的模型是不可能的。没错，有很多非规范化列。