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

时间:2011-04-05 20:08:29

标签: database reporting

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

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

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

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

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

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

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

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

2 个答案:

答案 0 :(得分:6)

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

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

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

答案 1 :(得分:3)

大多数通用表设计(其中列值是根据用户设置决定的)将导致性能不佳,因为所有查询都是动态的。

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

您能举例说明您的故事是什么吗?提出这个问题的一个例子就是你有一个产品表,有些产品只有5个属性而有些只有50个。正如我上面所说,你最好用50列创建表(如果你想要一个产品表)并且其他列在需要时为null。

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