sql - 典型的Kimball星型模式数据仓库-模型 View 可行吗？以及如何编码Gen

我有一个数据仓库，其中包含典型的星型模式，以及一堆执行以下操作的代码(显然要大很多，但这只是说明性的):

SELECT cdim.x
    ,SUM(fact.y) AS y
    ,dim.z
FROM fact
INNER JOIN conformed_dim AS cdim
    ON cdim.cdim_dim_id = fact.cdim_dim_id
INNER JOIN nonconformed_dim AS dim
    ON dim.ncdim_dim_id = fact.ncdim_dim_id
INNER JOIN date_dim AS ddim
    ON ddim.date_id = fact.date_id
WHERE fact.date_id = @date_id
GROUP BY cdim.x
    ,dim.z

我正在考虑将其替换为视图(MODEL_SYSTEM_1，例如)，以使其变为:

SELECT m.x
    ,SUM(m.y) AS y
    ,m.z
FROM MODEL_SYSTEM_1 AS m
WHERE m.date_id = @date_id
GROUP BY m.x
    ,m.z

但是视图MODEL_SYSTEM_1必须包含唯一的列名，并且如果继续执行此操作，我还担心优化程序的性能，因为我担心WHERE子句中不同事实和维度的所有项目都会进行了优化，因为视图将覆盖整个星星，并且无法对视图进行参数化设置(男孩，那不是很酷!)

所以我的问题是-

这种方法行吗，还是只是一种抽象，它会损害性能，并且除了语法更好之外，什么也没有给我带来什么？

在所有适当的PK和FK均已就位的情况下，最好的编码方式是生成这些视图，消除重复的列名(即使以后需要手动调整视图)的最佳方式是什么？我应该只是编写一些SQL将其从INFORMATION_SCHEMA中拉出来，还是已经有一个很好的示例了。

编辑:我已经对其进行了测试，即使在较大的进程上，性能似乎也相同-甚至加入了多个均使用这些视图的星星。

自动化主要是因为数据仓库中有许多这样的明星，而FK / PK已由设计人员正确完成，但我不想遍历所有表格或文档。我编写了一个脚本来生成视图(它还会生成表的缩写)，并且可以很好地从INFORMATION_SCHEMA自动生成骨架，然后可以在提交视图创建之前对其进行调整。

如果有人想要该代码，我可能会在这里发布。

最佳答案

我在照顾的几个数据仓库中使用了此技术。当我基于视图而不是表直接方法运行报表时，我没有注意到任何性能下降，但从未进行过详细的分析。

我使用SQL Server Management Studio中的设计器创建了视图，并且没有使用任何自动化方法。我无法想象架构会经常变化，以至于无论如何都应该进行自动化。您可能需要花费很长的时间来调整结果，就像将所有表拖到视图上一样!

要消除歧义，一种好的方法是在列名前添加其所属维的名称。这对报表编写者以及运行临时查询的任何人都是有帮助的。