我正在研究一个简单的数据集市，并且再次偶然发现了处理日期和时间。
这是车辆维护表格记录的设计，用于收集状态记录/备注以进行分析/可视化。此事实表中有几个日期和时间列。
我的问题是
事实表应该窄而长，而不是宽。有了这么多日期和时间列，它使表格变宽了。如果我在前端查询
LEFT JOIN和合并所有细节Vehicle.dim和VehMaintenance.fact输出，性能会不会很糟糕？现在想象一下我有更多的维度要加入，然后做一个将使它更宽LEFT JOIN。fact table我认为我的设计非常错误。Vehicle.dim链接回Date.dim. 我在某个地方读到了dimension table不应该链接回另一个的地方，除非它是 asnowflake schema并且如果它是parent / child.dimension table像这样链接两者仍然可以吗？
请注意，我fact table将在 15 分钟内从数据仓库批量更新。插入记录始终是一个INSERT查询（将有多个相同的记录，除了这些相同记录的日期不同）。中会有NULL一些date columns。
不，您的事实表并不宽，它只有 11 列。一旦你有超过 100 列左右，你就可以开始称它为宽。
如果您的表被正确索引，则不会，根本不会。不管你在每一个中有多少行。您将加入两个狭窄的桌子，它们的宽度也无关紧要。性能取决于您的用例以及您如何构建（例如索引）这些用例。
在没有看到实际查询的情况下，没有人可以得出结论性的建议，但是如果您只是
LEFT JOIN在两个表之间做一个简单的操作，那么您没有理由遇到任何问题。发生这种情况是因为您的表
Vehicle.dim不是真正的维度表。相反，它是一个准维度/事实表。这是因为它包含一个名为 的事实列manufactured_date。在理想的星型模式设计中，您将拥有一个Vehicle.fact存储 的表manufactured_date，并且位于您的两个维度表之间，Date.dim并且Vehicle.dim，这样您就不会直接链接两个维度表。同样，这并不理想，因为您正在走向雪花设计。从性能的角度来看，这可能会导致效率低下，并且可能会导致一些逻辑数据问题（例如，冗余数据显示在错误的上下文中），具体取决于您的用例。但是，如果你保持这种方式，在这个特定的设计中看起来也不会是世界末日。
我个人仍然建议创建一个
Vehicle.fact表，这样您就可以瞄准星型模式，特别是如果您Vehicle稍后添加更多关于 a 的事实，以防万一。