可以嵌套数据库视图吗？

Question

在 Oracle 的世界里，我的印象是基于其他观点的观点被认为是不好的做法。当试图解决性能问题和嵌套似乎过多并且隐藏了底层视图中不必要的复杂性时，我自己也曾抱怨过这一点。现在我发现自己的想法可能不是那么明确：

我的用户非常特别需要一个视图中的会计数字来匹配另一个对它们进行进一步处理的会计数字。如果他们对其中一个进行任何更改，他们希望另一个立即反映这一点，而无需任何人在几年内考虑这一要求，并且在他们解决问题时报告显示不匹配的数字。

在这种情况下可以嵌套视图吗？

如果内部视图包含另一个包含相关价格的重要视图（即，在确定价格时“总是”应该使用此视图），它会改变事情吗？

Answer 1

嵌套视图的主要问题是查询优化器更有可能感到困惑并产生次优计划。除此之外，在视图上使用视图没有特定的开销，除非它们做了优化器无法将谓词下推的事情。

这意味着最好的选择是尝试嵌套视图。查看您是否从报告中获得了合理的查询计划。如果它确实引起问题，那么您可能必须重新考虑您的策略。

Answer 2

我将从最佳实践的角度回答：

只有几次我会暂停使用视图上的视图。

1. 嵌套似乎已经失控……深度超过 3 层。我嵌套的原因是为了让代码更容易维护。一旦我开始讲到这一点，我就开始感觉有点太复杂了，难以理解。

2. 嵌套使用分析函数的视图。出于某种原因，我个人在使用分析函数嵌套视图方面没有很好的经验。

3. 本质上进行全面扫描的嵌套视图。虽然我认为查询优化器可能足够聪明来处理这个问题，但当我检查视图的逻辑时，它看起来是错误的。

4. 性能是一个非常令人担忧的问题。这并不是说优化器可能会出错，而是说在我发布它之前，我将对其进行测试，看看我是否无法找到更快的方法来做到这一点。

除此之外，我已经非常成功地使用了视图上的视图。

Answer 3

我认为您正处于滑坡上，代码重用和性能将发生冲突。您可以尝试一下，看看它对性能的影响有多大。我们这里有几个数据库，它们在视图之上堆叠了视图，坦率地说，性能很糟糕，现在每个参与的人都希望他们没有这样设计。

Answer 4

编码时间、代码的易用性或质量以及性能之间总是需要权衡。

嵌套视图确实很容易编码，并且在适当的情况下，也使其易于阅读。它还可以减少时间。可以说，它会降低质量并经常降低性能……但降低了多少？

这都是主观的。如果有道理，那就跟着它走吧。不要过早优化您的代码。

Answer 5

最佳实践并不总是涵盖所有内容。我认为你有一个明确的理由来嵌套它们，就这一次。

Answer 6

我在 Oracle 10g R2 中将视图嵌套了 3 层。性能似乎与视图中的选择语句相关，而不是与视图深度相关。特别是“IN”子句似乎造成了很多麻烦。

Answer 7

在构建复杂的数据库查询的过程中值得注意的是，有时嵌套视图是最好的 - 例如，如果您需要在 2 列上构建任何数学运算符，例如 SUM(Col1, Col2) ，它可能会更好嵌套视图，使总和本身就是一列，而不必执行类似

“SELECT Total / SUM(Col1, Col2), SUM(Col1, Col2) * 2, Col1 / SUM(Col1, Col2) ... “

但是我不确定我是否理解 100% - 为什么需要 2 个视图？难道两个用户都不能查看第一个视图并在该视图之上的另一层视图中导出进一步的处理吗？

Answer 8

使用视图的最佳理由是：

1. 防止重复相同的查询。
2. 防止其他查询编写器直接访问表
3. 创建一个安全层（类似于#2）。

我确实意识到它还可以帮助简化更复杂的查询，但您会习惯它。您可能会发现用户定义的函数（表）可能是更好的解决方案。无论哪种方式，性能都会受到影响。

Answer 9

嵌套视图是有意义的。请注意不要让它们太笼统。

---

我确实看到一个系统有一个视图，其中明确提到了 14 个表，其中一些与外部自联接连接，一些“表”本身就是视图。我不太喜欢它，但 DBMS 处理它的能力出奇地好（考虑到那是在 80 年代末）。许多模式是由数据建模工具机器生成的。

CREATE VIEW IBB_V_Project AS
    SELECT  A.Project_Iref,
            A.Section_Iref,
            B.Section_Eref,
            N.Company_Iref,
            N.Company_Name,
            A.Product_Desc,
            A.Project_Type_Iref,
            D.Project_Type,
            A.Person_Iref,
            F.Full_Name,
            A.Respon_Iref,
            G.Post_Location,
            A.Project_Stat_Iref,
            E.Project_Status,
            A.Source_Iref,
            I.Source,
            A.Sic_Iref,
            L.Sic_Eref,
            A.Op_Activity_Iref,
            M.Op_Activity_Desc,
            A.Involve_Iref,
            K.IBB_Involvement,
            A.Nature_Iref,
            C.Nature_Of_Next_Act,
            A.Internat_Mobile,
            A.Whether_Cop_Case,
            A.Closed_Ind,
            A.Next_Action_Date,
            A.Creation_Date,
            A.Last_Edit_Date,
            A.Last_Editor_Iref,
            H.Logname

    FROM    IBB_Project A,
            IBB_Section B,
            IBB_R_Proj_Type D,
            IBB_R_Project_Stat E,
            IBB_Personnel H,
            OUTER IBB_R_Next_Act C,
            OUTER IBB_Personnel F,
            OUTER (IBB_Post_Respon X, OUTER IBB_V_Post_Resp2 G),
            OUTER IBB_R_Source I,
            OUTER IBB_R_Involvement K,
            OUTER IBB_Sic L,
            OUTER IBB_Op_Act M,
            OUTER IBB_V_Proj_Co2 N

    WHERE   A.Section_Iref      = B.Section_Iref
      AND   A.Project_Type_Iref = D.Project_Type_Iref
      AND   A.Project_Stat_Iref = E.Project_Stat_Iref
      AND   A.Last_Editor_Iref  = H.Person_Iref
      AND   A.Nature_Iref       = C.Nature_Iref
      AND   A.Person_Iref       = F.Person_Iref
      AND   A.Respon_Iref       = X.Respon_Iref
      AND   X.Respon_Iref       = G.Person_Iref
      AND   A.Source_Iref       = I.Source_Iref
      AND   A.Sic_Iref          = L.Sic_Iref
      AND   A.Op_Activity_Iref  = M.Op_Activity_Iref
      AND   A.Project_Iref      = N.Project_Iref
      AND   A.Involve_Iref      = K.Involve_Iref;

外连接表示法特定于 Informix（它现在也支持 SQL 标准表示法）。

请注意，IBB_V_Post_Resp2 和 IBB_V_Proj_Co2 本身都是视图。
事实上，IBB_V_Proj_Co2 是一个 3 表视图，具体细节未知，但
形式：

CREATE VIEW IBB_V_Proj_Co2 AS
    SELECT  A.Project_Iref,
            A.Some_Other_Col col01,
            B.Xxxx_Iref,
            B.Some_Other_Col col02,
            C.Yyyy_Iref,
            C.Some_Other_Col col03
    FROM    IBB_Project A,
            OUTER (IBB_R_Xxxx B, IBB_R_Yyyy C)
    WHERE   A.Xxxx_Iref = B.Xxxx_IrEf
      AND   B.Yyyy_Iref = C.Yyyy_Iref;

这意味着 IBB_V_Project 视图有一个外部自连接
IBB_项目。 IBB_V_Post_Resp2 视图可能涉及 3 个表
（我的笔记有点不清楚，早在 1993 年，当我记录这些信息时）。

CREATE VIEW IBB_V_Post_Resp2 AS
    SELECT  A.Person_Iref,
            A.Some_Other_Col col01,
            B.Xxxx_Iref,
            B.Some_Other_Col col02,
            C.Yyyy_Iref,
            C.Some_Other_Col col03
    FROM    IBB_Personnel A,
            IBB_R_Xxxx B,
            IBB_R_Yyyy C
    WHERE   A.Xxxx_Iref = B.Xxxx_Iref
      AND   B.Yyyy_Iref = C.Yyyy_Iref;

Zzzz_Iref 列是 SERIAL 或 INTEGER 外键
引用 SERIAL 键。

主视图定义引用了 14 个表，其中有 4 个内连接和 9 个表
外连接。当考虑到交叉引用的视图时，有
总共18张表，有7个内连接和10个外连接。

Answer 10

真的不想陷入整个嵌套视图的事情，

想一想这个想法...你试图加入到一个表中以查找不匹配...我会使用 Oracle 函数“减”.. ..MINUS 从第一个表中选择元素，然后删除第二个 SELECT 语句也返回的行。

选择号码
FROM (SELECT 1 AS 编号
来自双
联合所有
选择 2 作为编号
来自双
联合所有
选择 3 作为编号
FROM DUAL) base_view

MINUS

SELECT 2 AS num
来自双