为未知列数设计数据表的最佳方法？

Question

我正在尝试构建一个最能支持以下标准的数据表结构:

1)我不知道该表必须有多少列.

• 在某些情况下我可能需要6列,在其他情况下可能需要10列.我不希望这个表需要20个或更多列,但我也不能保证永远不需要.

2)我需要考虑存储空间和报告速度.

• 此表将需要存储数百万条记录,并将针对此表运行报告.我知道从报告的角度来看,高度规范化的表很难实现,所以我想对报告进行去规范化.但是,我也不知道为了避免一些规范化而简单地默认为一些大量的列是一个好主意,因为我可能会在表的末尾的许多列中结束大量的NULLS,那些(我认为)会占用一些存储空间.

3)如果我必须在存储空间和报告性能之间做出选择,我会支持性能.

我不是商业智能专家,我不是T-SQL大师(我将使用SQL Server),所以我确实在这里有一些我忽略的优点.因此,我再次转向辉煌的SO社区寻求建议,并且有一些感觉被撞到我厚厚的头骨中.

在这种情况下你会如何设计表？我错过了哪些细节,仍需要考虑？

Answer 1

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

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

你能举个例子来说明你的故事的目的吗？提出这个问题的例子之一是，当您有一个产品表，有些产品只有 5 个属性，有些产品有 50 个属性。正如我上面所说，您最好创建包含 50 列的表（如果您想要一个产品表）并在需要时将其他列设置为空。

报告工具和大多数 RDBMS 在聚合和分组期间可以很好地处理空值。

Answer 2

表的列表示要存储的实体的规范.要说您不知道将存储多少列意味着您不知道要存储的内容的规范.换句话说,你想要建立一个系统而不知道它将存储什么.关系数据库从根本上不是为处理这种情况而设计的,并且性能良好且可维护.为了执行良好且可维护,关系数据库依赖于花时间来确定要存储的实体的性质及其属性,然后构建适当的模式.

因此,使用关系数据库的最佳性能和最易维护的解决方案是根据需要构建模式,这意味着在需要时收集有关存储内容的规范.

也就是说,有一些关系数据库的替代品,例如所谓的"nosql"数据库,它可能比关系数据库更适合超级弹性设计.这些示例包括MongoDB和CouchDB.