我正在许多OLTP表上创建数据仓库模型。 a）我可以使用星型模式，也可以b）平面表模型表。
许多人认为不需要维度星形架构模型表；因为大多数数据都可以在一个表中报告。此外，当性能和存储成为问题时，将创建星型架构Kimball。有人声称，随着技术的改进，数据可以在一个表中显示。
我还是应该将数据分为维度/事实表，还是直接在数据仓库中使用平面表？
在Microsoft Azure中，建议使用扁平表还是星形模式？
在这个问题上，我相信AWS Redshift员工更喜欢平板宽桌。 Performance of Flat Tables Vs Dimension and Facts
答案 0 :(得分：1)
我认为最好用“这取决于您的业务需求，时间和资源”来回答这个问题。我认为有理由同时支持这两种情况，具体取决于您的情况。但是，根据我的经验，如果您要构建这些表以供大量报告和其他分析使用，那么我将采用星形模式。
我猜您要插入的表仍处于第三范式？在这两种情况下，您仍在取消规范化，但是假设这是您长期创建的东西，我认为Star会更好地满足您的目的。 Kimball不仅因为技术优化的原因而建议了尺寸/事实的关系，还出于商业原因。
示例：您具有一次构建的产品表，并且具有将其连接到的销售事实。在接下来的6个月中，也许现在有人希望获得与库存或折扣相关的所有业务指标，很可能两者兼而有之。您已经有一个适合的产品表。如果您的销售表只有一个扁平化的表，其中包含产品，那么最终您将再次为库存和产品折扣执行相同的工作。当产品被分离出来时，将一个联接应用于这三个事实表中的每一个事实将更容易，而且将来肯定还会出现更多联接。从长远来看，在Star上花费的时间更少，因为您可以迭代添加新的可测量数字。
维护该产品表或任何维表（可衡量金额的上下文）在工作时要容易得多。任何时候只要有新列即可更好地对产品进行分类，例如
在大多数情况下，只要您具有星形模式（例如SSAS和PowerPivot），任何建模工具都可以轻松使用，就像拖放报告一样（如连接到模型的数据透视表）