Question

我有一个设计问题。

我必须在表格中存储大约100个不同的属性，这些属性也应该是可搜索的。因此，每个属性都将存储在自己的列中。每个属性的值总是小于200，所以我决定使用TINYINT作为每个属性的数据类型。

创建一个包含大约100列（每个TINYINT）的表是一个好主意吗？这个设计可能有什么问题？

或者我应该将属性分类到一些组（说4组）并将它们存储在4个不同的表中（每个表大约有25列）

或者我必须遵循的任何其他数据存储技术。

例如，表格是Table1，它包含每个TINYINT数据类型的Column1，Column2 ...... Column100列。

由于每行的大小将非常小，我可以按照上面的说明进行操作吗？

我只是想知道它的优点/缺点。

如果您认为拥有100列的表格不是一个好主意，那么请建议其他替代方案。

请注意，我不想以复合形式存储信息（例如，几个xml列）

提前致谢

Answer 1

这里的多对多设置不会有效吗？

说表A将有一个小部件列表，您的属性将应用于

表B包含您的属性类型（颜色，大小，重量等），每个属性作为不同的行（不是列）

表C具有小部件ID（表A）和属性类型（表B）的外键，然后它实际上具有属性值

这样，当您要添加新属性时，您不必更改表结构，只需向表C添加新的属性类型行

Answer 2

可以拥有100列。为什么不？只需使用代码生成来减少此列的手写内容。

Answer 3

我不会担心列数本身（除非你使用一些非常糟糕的关系引擎，在这种情况下升级到一个体面的将是我最衷心的建议 - 什么引擎[s]你计划/需要支持，顺便说一下？）但是关于可搜索性。

表格是否需要通过属性的值进行有效搜索？如果你在该表上需要100个索引，这可能会使插入和更新操作变得缓慢 - 这些修改的频率（对表的读取，特别是对属性值的搜索）以及它们对你的速度有多重要？

如果你“需要一切”，那么可能就没有“完美”解决方案的灵丹妙药，只是在令人不快的替代方案中妥协 - 需要更多信息来衡量它们。典型的行是“稀疏的”，即大多数是NULL，只有少数100个属性对于任何给定的行都是“活动的”（每个只有不同的子集）？是否（至少在统计上）属性组之间存在某种相关性（例如，当属性12值为93时，属性41值为27或28时大多数时间都是这样的）？

Answer 4

在你的上一次出现，在我看来你可能有一个糟糕的设计。这些列的性质是什么？您是否存储了不应该在一起的信息，是否存储了相关表格中的信息？

因此，我们最需要帮助的是了解您拥有的数据的性质。

将会是什么 column1，column3，column10 vice column4，column15，column20，column25

Answer 5

我有一张250列的桌子。没有错。对于某些情况，它是如何工作的。

除非您定义的某些列具有“本身”作为独立实体的含义，并且它们可以由多行共享。在这种情况下，将另一个表中的列集标准化，并将列放在原始表中（可能使用外键约束）是有意义的

Answer 6

我认为正确的方法是让表格看起来更像：

CREATE TABLE [dbo].[Settings](
    [key] [varchar](250) NOT NULL,
    [value] tinyint NOT NULL
) ON [PRIMARY]

在键列上放置一个索引。您最终可以创建一个用户可以更新值的页面。

在现实世界中做了很多这些，我不明白为什么有人会主张让每个变量都是自己的专栏。到目前为止，您有“大约100个不同的属性”，您认为您不想添加和删除此列表？每次执行此操作都是表更改和生产版本？您将无法构建一些东西来将维护交给高级用户。您的报告也会被硬编码吗？事情起飞，你达到1,024的最大列数，你会重做整件事吗？

扩展上表没有任何意义 - 添加Category，LastEditDate，LastEditBy，IsActive等，或创建归档功能。使用基于列的解决方案做这件事更加尴尬。

对于这些少量数据，性能不会有任何不同，但是每次列表更改时依赖程序员来制作和发布更改是不可行的。

列太多设计问题

6 个答案: