3

我有一个包含典型星型模式的数据仓库，还有一大堆代码可以做这样的事情（显然要大得多，但这只是说明性的）：

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 子句中跨不同事实和维度的所有项目都会得到优化，因为视图将跨越整个恒星，并且视图无法参数化（男孩，那不是很酷！）

所以我的问题是——

  1. 这种方法可以吗，或者它只是一种抽象，会损害性能并且除了更好的语法之外没有给我任何东西？

  2. 考虑到所有适当的 PK 和 FK 都已到位，对这些视图进行代码生成、消除重复的列名（即使稍后需要手动调整视图）的最佳方法是什么？我是否应该只编写一些 SQL 将其从其中提取出来，INFORMATION_SCHEMA或者是否已经有一个很好的示例可用。

编辑：我已经对其进行了测试，即使在更大的过程中，性能似乎也是一样的——甚至加入了多个使用这些视图的星星。

自动化主要是因为数据仓库里面有很多这样的star，设计者已经做好了FK/PK，但我不想把所有的表格或文档都挑一遍。我编写了一个脚本来生成视图（它还生成表格的缩写），它可以很好地从 自动生成骨架INFORMATION_SCHEMA，然后可以在提交视图创建之前对其进行调整。

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

4

3 回答 3

2

  1. 我已经在我负责的几个数据仓库中使用了这种技术。在运行基于视图的报告与直接使用表格方法时，我没有注意到任何性能下降，但从未进行过详细分析。

  2. 我使用 SQL Server 管理工作室中的设计器创建了视图，没有使用任何自动化方法。我无法想象架构经常发生变化，以至于自动化它无论如何都是值得的。您可能会花费与首先将所有表格拖到视图上一样长的时间来调整结果！

为了消除歧义，一个好的方法是在列名前加上它所属的维度的名称。这对报告编写者和运行临时查询的任何人都有帮助。

于 2008-09-25T18:36:48.910 回答
1

将一个或多个视图变成一个或多个汇总事实表并将其具体化。这些仅在刷新主事实表时才需要刷新。物化视图的查询速度会更快，如果您有很多可以通过摘要满足的查询，这可能是一个胜利。

如果您有大量此类摘要或希望经常更改它们，则可以使用数据字典或信息模式视图生成 SQL 以创建表。

但是，我猜您不太可能经常更改这些内容，因此自动生成视图定义可能不值得麻烦。

于 2008-09-24T17:24:11.090 回答
1

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

于 2009-10-26T15:46:54.760 回答