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

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以创建表。

但是，我想我们不太可能经常更改这些设置，因此自动生成视图定义可能不值得。

• 我已经在我要管理的几个数据仓库中使用了这种技术。当我基于视图而不是表直接方法运行报表时，我没有注意到任何性能下降，但从未进行过详细的分析。
• 我是使用SQL Server Management Studio中的设计器创建视图的，没有使用任何自动化方法。我无法想象架构会经常更改，以至于无论如何都值得对其进行自动化。我们可能需要花费很长的时间来调整结果，就像将所有表拖到视图上一样！

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

如果碰巧使用了MS SQL Server，则可以尝试使用内联UDF，它尽可能接近参数化视图。