Ist es OK, Datenbankansichten zu verschachteln?

Question

In der Welt des Orakels habe ich den Eindruck, dass Ansichten, die auf anderen Ansichten basieren, als schlechte Praxis angesehen werden. Ich selbst habe mich darüber beschwert, als der Versuch, Leistungsprobleme zu lösen, und die Verschachtelung übertrieben schienen und unnötige Komplexität in den zugrunde liegenden Ansichten versteckten. Jetzt bin ich in der Situation, dass ich denke, dass es vielleicht nicht so eindeutig ist:

Ich habe Benutzer, die ganz gezielt die Buchhaltungszahlen einer Ansicht mit denen einer anderen Ansicht abgleichen müssen, in der sie weiterverarbeitet werden. Wenn sie in der einen Ansicht etwas ändern, soll die andere das sofort widerspiegeln, ohne dass jemand in ein paar Jahren an diese Anforderung denken muss und die Berichte nicht übereinstimmende Zahlen zeigen, während sie die Dinge herausfinden.

Ist es in diesem Fall in Ordnung, Ansichten zu verschachteln?

Ändert es etwas, wenn die innere Sicht eine weitere, wichtige Sicht enthält, die relevante Preise enthält (d.h. man soll diese Sicht "immer" bei der Preisermittlung verwenden)?

Answer 1

Ich verschachtle Ansichten 3 Ebenen tief in Oracle 10g R2. Die Leistung scheint eher mit den Select-Anweisungen in den Ansichten als mit der Ansichtstiefe zusammenzuhängen. Insbesondere die "IN"-Klausel scheint eine Menge Probleme zu verursachen.

Answer 2

Bei der Erstellung komplizierter Datenbankabfragen sind verschachtelte Ansichten manchmal die beste Lösung. Wenn Sie zum Beispiel einen mathematischen Operator benötigen, der auf zwei Spalten basiert, z. B. SUMME(Spalte1, Spalte2), kann es besser sein, Ansichten so zu verschachteln, dass die Summe eine eigene Spalte ist, anstatt etwas zu tun wie

"SELECT Gesamt / SUMME(Spalte1, Spalte2), SUMME(Spalte1, Spalte2) * 2, Spalte1 / SUMME(Spalte1, Spalte2) ..."

Ich bin mir jedoch nicht sicher, ob ich es zu 100 % verstehe - warum sind 2 Ansichten erforderlich? Können nicht beide Benutzer auf die eine Ansicht schauen und die weitere Verarbeitung in einer Ansicht eine Ebene darüber abgeleitet werden?

Answer 3

Die besten Gründe, eine Ansicht zu verwenden, sind:

1. verhindern, dass dieselbe Abfrage doppelt ausgeführt wird.
2. den direkten Zugriff auf Tabellen durch andere Abfrageautoren verhindern
3. eine Sicherheitsebene zu schaffen (ähnlich wie bei Nr. 2).

Ich weiß, dass es auch helfen kann, eine komplexere Abfrage zu vereinfachen, aber man gewöhnt sich daran. Vielleicht finden Sie, dass eine benutzerdefinierte Funktion (Tabelle) eine bessere Lösung ist. So oder so, die Leistung wird darunter leiden.

Answer 4

Verschachtelte Ansichten können sinnvoll sein. Achten Sie nur darauf, dass Sie sie nicht zu allgemein gestalten.

---

Ich habe ein System gesehen, das eine Ansicht mit 14 ausdrücklich erwähnten Tabellen hatte, von denen einige mit äußeren Self-Joins verbunden waren, und einige der "Tabellen" waren selbst Ansichten. Das gefiel mir nicht besonders, aber das DBMS kam damit erstaunlich gut zurecht (wenn man bedenkt, dass das in den späten 80er Jahren war). Ein großer Teil des Schemas wurde von einem Datenmodellierungstool maschinell erstellt.

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;

Die Notation der äußeren Verknüpfung ist spezifisch für Informix (das jetzt auch die SQL-Standardnotation unterstützt).

Beachten Sie, dass IBB_V_Post_Resp2 und IBB_V_Proj_Co2 beide selbst Ansichten sind. Tatsächlich war IBB_V_Proj_Co2 eine 3-Tabellen-Ansicht, deren genaue Details nicht bekannt sind, aber von der der Form:

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;

Dies bedeutet, dass die Ansicht IBB_V_Project eine äußere Selbstverknüpfung mit IBB_Projekt hat. Die Ansicht IBB_V_Post_Resp2 umfasste wahrscheinlich 3 Tabellen involviert (meine Notizen dazu waren damals, 1993, als ich diese Informationen aufzeichnete, etwas unklar).

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;

Die Zzzz_Iref-Spalten waren entweder SERIAL- oder INTEGER-Fremdschlüssel die auf einen SERIAL-Schlüssel verweisen.

Die Definition der primären Ansicht bezieht sich auf 14 Tabellen, mit 4 inneren Joins und 9 äußeren Joins. Wenn die Querverweise berücksichtigt werden, gibt es insgesamt 18 Tabellen, mit 7 inneren und 10 äußeren Joins.

Answer 5

Ich möchte mich nicht in die ganze Sache mit den verschachtelten Ansichten einmischen.

Denken Sie einmal darüber nach... Sie versuchen, eine Tabelle zu verknüpfen, um Unstimmigkeiten zu finden... ich würde die Oracle-Funktion 'minus'....MINUS verwenden, die Elemente aus der ersten Tabelle auswählt und dann Zeilen entfernt, die auch von der zweiten SELECT-Anweisung zurückgegeben werden.

S FROM (SELECT 1 AS num FROM DUAL UNION ALL SELECT 2 AS num FROM DUAL UNION ALL SELECT 3 AS num FROM DUAL) base_view

MINUS

S FROM DUAL