假设您正在为具有许多属性（2400+）的实体建模，远远超过给定数据库引擎的物理限制（例如~1000 SQL Server）。除了域名/候选键之外，对这些数据点的相对重要性（哪些是最热门/最常用的）一无所知，您将如何实现它？
A）EAV。 （嘘......本机关系工具抛出窗外。）
B）直接穿过。第一个表有一个主键和1000列，直到极限。下表是1000，外键是第一个。最后一张表是剩余的400，也是外键。
C）在ceil( n / limit )个表格中均匀划线。每个表都有偶数列，外键键到第一个表。 800,800,800。
D）别的......
为什么？
编辑：这更像是一个哲学/一般性问题，与任何特定限制或引擎无关。
编辑^ 2：正如许多人所指出的，数据可能没有标准化。按照惯例，当时的业务限制使深入研究成为不可能。
答案 0 :(得分：6)
将Sparse Columns用于最多30000列。与EAV或XML相比的最大优势是，您可以将Filtered Indexes与稀疏列结合使用，以便对常见属性进行非常有效的搜索。
答案 1 :(得分：6)
我的解决方案：进一步调查。具体来说，确定表是否真正正常化（在2400列，这似乎不太可能）。
如果没有，重组直到完全标准化（此时每个表可能少于1000列）。
如果已经完全标准化，则建立（尽可能）每个属性的近似人口频率。将最常出现的属性放在实体的“主”表中，对于不常用的属性使用2或3个附加表。 （尝试将出现频率作为确定哪些字段应该放在哪些表上的标准。）
只考虑EAV用于极其稀疏填充的属性（最好不要考虑）。
答案 2 :(得分：4)
在这方面没有太多知识，我认为具有如此多属性的实体真的需要重新设计。我的意思是将大东西分成逻辑上连接的较小部分。
答案 3 :(得分：2)
对我来说，关键是这件作品：
对这些数据点的相对重要性一无所知（哪些数据点最热/最常使用）
如果你知道哪些字段更重要，我会把那些更重要的字段放在“native”表中，让EAV结构处理剩下的部分。
事情是，如果没有这些信息，你无论如何都会失明。无论您有2400个字段还是24个字段，您都应该对数据点的含义（以及相对重要性，或至少是逻辑分组）有所了解。
答案 4 :(得分：1)
我使用一对多的属性表和实体的外键。
例如
实体：id，
attrs：id，entity_id，attr_name，value
ADDED
或者Butler Lampson会说，“计算机科学中的所有问题都可以通过另一层次的间接解决”
答案 5 :(得分：0)
我会旋转列并使它们成行。您可以将其作为fkey返回到包含所有可能属性列表的查找表，而不是将包含属性名称的列作为字符串（nvarchar）。
以这种方式旋转它意味着你：
答案 6 :(得分：0)
我会仔细研究数据模型 更仔细。这是第三次正常吗？ 形成？是否有属性组 应该在逻辑上分组 一起进入自己的桌子？
假设它正常化了 实体真的有2400多个属性，我 嘘声不会那么快 EAV model。恕我直言，这是最好的， 最灵活的解决方案 你描述过的情况。它为您提供了对稀疏数据的内置支持，并为您提供了良好的搜索速度，因为任何给定属性的值都可以在单个索引中找到。
答案 7 :(得分：0)
我想使用垂直（增加行数）方法而不是水平方式（增加列数）。
您可以尝试这种方法，如
表 - id，property_name - property_value。
方法的优点是，在引入新属性/列时无需更改/创建表。