为未知数量的列设计数据表的最佳方法是什么？

Question

我试图建立一个数据表结构，最好支持以下标准：

1）我不知道表有多少列。

• 我在某些情况下可能需要6列，或在其他情况下需要10列。我不认为这张桌子需要20列或更多列，但我也不能保证永远不会需要。

2）我需要考虑存储空间和报告速度。

• 此表需要存储数百万条记录，并且报表将针对此表运行。我知道摆脱高度规范化的表格从报告的角度来看很困难，所以我想解除报告的规范化。但是，我也不知道是否为了避免一些规范化而简单地违约到大量的列是一个好主意，因为我可能会在表的末尾的许多列中结束大量的NULLS，那些将（我认为）都占用了一些存储空间。

3）如果我必须在存储空间和报表性能之间进行选择，我会在性能方面表现出色。我不是一个商业智能专家，我不是一个T-SQL专家（我将使用SQL Server），所以我很确定在这里有很好的一点，我只是忽略了它。因此，我再次转向了精彩的SO社区寻求建议，并且让我的头骨有一些感觉。

在这种情况下你会如何设计表格？我错过了什么细节，仍然需要考虑？

Answer 1

大多数通用表设计的列值根据用户设置决定/如此将导致性能较差，因为所有查询都是动态的。

合理的做法是提出对列数的估计，并让未使用的列最初为空。

你能举个例子说明你的故事是什么吗？引发这个问题的一个例子是当你有一个产品表时，有些产品只有5个属性，有些产品有50个。正如我上面所说的，你最好用50列创建表（如果你想有一个产品表），并在需要时将其他列作为null。

报告工具和大多数RDBMS在聚合和分组过程中处理空值。

Answer 2

表中的列表示要存储的实体的规格。说你不知道有多少列将被存储意味着你不知道要存储的东西的规格。换句话说，你想建立一个系统而不知道它会存储什么。关系数据库基本上没有设计成处理这个并且性能良好且可维护。为了表现良好且可维护，关系数据库依赖花费时间来确定要存储的实体的属性及其属性，然后构建适当的模式。

因此，使用关系数据库的最佳性能和最可维护的解决方案是根据需要构建模式，这意味着需要收集有关要存储的规格。

也就是说，关系数据库有其他选择，比如所谓的“nosql”数据库，它可能比关系数据库更适合超级弹性设计的需要。这些示例包括MongoDB和CouchDB。