在为雪花数据仓库设计数据模型时，是否有关于哪种类型的模型具有最佳性能的一般规则？具体来说，比较传统的星型架构与宽表
架构典型的事实数据表具有存储字段(如说明(的维度的代理键。如果结构进一步非规范化，并且这些描述被移动(或也在(事实数据表上，该怎么办？这更符合"一张大桌子"的做法。更改任何维度或事实的值都需要在"事实"表中创建新记录，这显然会生成更多数据">
答案在某种程度上取决于您的具体情况。 在设计架构时，通常必须平衡从许多不同源/表引入数据的易用性/速度/可恢复性，该模型易于使用者理解(例如，编写复杂的分析查询(并在负载下表现良好。
我发现以星形/雪花格式维护核心数据模型可以独立摄取/转换/符合所有相应的事实和维度表。
但是，我有另一个转换/非规范化层，可以将该模型扁平化为分析就绪数据集。 根据数据集大小和数据新鲜度要求，这可以通过一个简单的 CTAS 语句来完成，该语句将必要的数据汇集在一起 + 交换(此解决方案可以随时运行，而不会中断分析查询(
出于性能原因，扁平表对于实时连接到Snowflake的BI工具和分析师至关重要。 对于不是SQL大师的分析师来说，它抽象出所有底层联接的复杂性。
这个问题之前已经有很多变体被问过，最新的是雪花 sproc 与独立 sql。
Snowflake 的混合列/微分区表存储(以及其他具有纯列结构的数据库(意味着旧事实不再有效，或者在较小程度上有效。
如果你有一个星型模式模型，这通常意味着你有一个按批处理更新的数据仓库，而不是由许多小事务更新。 这意味着维护"一张大桌子"的成本可能不会令人望而却步，应该进行调查。 对于大多数数据使用者来说，一个大表肯定是最简单的。