database-design - 一个或多个事实表？

Question

我正在尝试建立一个数据集市。

我有很多方面，还有一些措施-事实。在业务方面，每项措施都与各个方面相关。有一种标准的方法，就是将所有措施都放在一个大的事实表中。

但是我有一个主意:如果我为每个量度使用单独的事实表怎么办？它对数据库性能，解决方案可扩展性等有何作用？

编辑:::
在真正复杂的公司环境中，将有大量基于olap多维数据集的解决方案。因此，需求首先是易于扩展和维护，然后是性能

Answer 1

悬崖笔记:我看到一个事实表/度量的概念带来了可扩展性问题。

如果您的目标是“可扩展性和维护性”，那么您可以考虑采用行业标准的方法...例如Kimball，并首先按照业务流程对事实进行分组，其次按照符合维度的粒度进行分组。我很乐意争辩说，这将提供最大的灵活性和可扩展性，同时还可以通过标准化确保可扩展性和维护性。

另外，如果您为每个度量设计单独的事实表，则SAN管理员会讨厌您的胆量，因为您正在通过度量数量有效地增加空间需求……至少在最初时，而当前所有度量都适合于单个事实表。

针对DW的查询性能也将是一个问题...报告和/或临时查询将必须进行扫描(或查找...如果您的san-admin仍在与您交谈并且足够慷慨地授予您必要的信息，您需要组合多于一种度量的任何时间的空间，以正确索引您的事实表垃圾。

我们甚至还没有讨论过olap多维数据集，但是我已经在担心您将遇到的处理问题。全面的表扫描性能...或分区扫描...如果您在事实表中实现分区...您现在应该使用SQL 2012了...我正在寻找ColumnStore索引!