Czy można zagnieździć widoki bazy danych?

Question

W świecie wyroczni mam wrażenie, że poglądy oparte na innych poglądach uważane są za złe praktyki. Sam narzekałem na to, gdy próby rozwiązania problemów z wydajnością i zagnieżdżanie wydawały się przesadne i ukrywały niepotrzebną złożoność podstawowych poglądów. Teraz znajduję się w sytuacji, gdy myślę, że to może nie być tak jednoznaczne:

Mam użytkowników, którzy bardzo potrzebują numerów ewidencyjnych z jednego widoku, aby dopasować je do innego, który przetwarza je dalej. Jeśli kiedykolwiek zmienią coś w jednym, chcą, aby drugi natychmiast to odzwierciedlił, bez konieczności myślenia o tym wymogu za kilka lat i raportów pokazujących niepasujące liczby, gdy będą wymyślać różne rzeczy.

Czy w tym przypadku można zagnieździć widoki?

Czy to zmienia sytuację, jeśli widok wewnętrzny zawiera dodatkowy, ważny widok zawierający odpowiednie ceny (np.

Answer 1

Głównym problemem z widokami zagnieżdżania jest to, że optymalizator zapytań jest bardziej podatny na dezorientację i tworzy nieoptymalny plan. Poza tym nie ma szczególnego narzutu na używanie widoków na widoki, chyba że robią coś, do czego nie ma predyspozycji optymalizator.

Oznacza to, że najlepszą opcją jest wypróbowanie zagnieżdżonych widoków. Sprawdź, czy otrzymasz rozsądne plany zapytania z raportów. Jeśli powoduje problemy, być może trzeba będzie przemyśleć swoją strategię.

Answer 2

Najlepsza praktyka nie zawsze obejmuje wszystko. Myślę, że macie jednoznaczne uzasadnienie dla ich zagnieżdżenia, tylko ten jeden raz.

Answer 3

Warto również zauważyć, że w procesie budowania skomplikowanych zapytań do bazy danych czasami najlepsze są widoki zagnieżdżone - na przykład, jeśli potrzebujesz operatora matematycznego zbudowanego na 2 kolumnach, na przykład SUM (Col1, Col2) lepiej jest zagnieżdżać widoki, tak aby suma była sama w sobie kolumną, zamiast robić coś w rodzaju "SELECT Total/SUM (Col1, Col2), SUMA (Col1, Col2) * 2, Col1/SUM" (Col1, Col2) ... "

Jednak nie jestem pewien, czy rozumiem 100% - Dlaczego potrzebne są 2 widoki? Czy obaj użytkownicy nie mogą spojrzeć na widok 1, a dalsze przetwarzanie można uzyskać w widoku innej warstwy powyżej tego?

Answer 4

Jestem zagnieżdżanie widoki 3 poziomy głęboko w Oracle 10g R2. Wydajność wydaje się być powiązana z wybranymi instrukcjami w widokach, a nie z głębią widoku. W szczególności klauzula "IN" wydaje się powodować wiele problemów.

Answer 5

Myślę, że znajdujesz się na śliskiej ścieżce, gdzie koduje się ponowne użycie kodu i wydajność. Możesz spróbować i zobaczyć, jak bardzo wpłynie to na wydajność. Mamy tu kilka baz danych, w których zgromadzono poglądy na temat poglądów i szczerze mówiąc, wydajność jest nieszczęśliwa, a teraz wszyscy zaangażowani chcieli tego, czego nie zaprojektowali w ten sposób.

Answer 6

najlepszych powodów do korzystania z widoku byłoby:

1. zapobiegają powielanie tego samego zapytania.
2. uniemożliwić bezpośredni dostęp do tabel przez innych twórców zapytań
3. utworzyć warstwę zabezpieczeń (podobnie jak # 2).

Zdaję sobie sprawę, że może to również pomóc uprościć bardziej złożone zapytanie, ale przyzwyczaić się do niego. Może się okazać, że funkcja zdefiniowana przez użytkownika (tabela) może być lepszym rozwiązaniem. Tak czy inaczej, wydajność będzie hitem.

Answer 7

Zawsze istnieje kompromis między czasem kodowania, łatwością lub jakością kodu, a wydajnością.

Zagnieżdżanie widoków jest naprawdę łatwe do zakodowania i, biorąc pod uwagę odpowiednie okoliczności, ułatwia czytanie. Może również skrócić czas. To prawdopodobnie obniża jakość i często zmniejsza wydajność ... ale o ile?

Wszystko to jest subiektywne. Jeśli ma to sens, przeturlaj się z nim. Nie przedwcześnie optymalizuj swojego kodu.

Answer 8

Zagnieżdżone widoki mogą mieć sens. Po prostu uważaj, aby nie uczynić ich zbyt ogólnymi.

---

widziałem system, który miał widok z 14 tabel wymienionych wyraźnie, niektóre z nich wiąże się z self-dołącza zewnętrzny, a niektóre z „tabel” były same poglądy. Nie podobało mi się to bardzo, ale DBMS poradził sobie z tym zadziwiająco dobrze (biorąc pod uwagę, że powrócił pod koniec lat 80.). Wiele schematów zostało wygenerowanych maszynowo za pomocą narzędzia do modelowania danych.

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; 

Zewnętrzna notacja sprzężenia jest specyficzna dla Informix (która teraz obsługuje także notację standardową SQL).

Należy zauważyć, że IBB_V_Post_Resp2 i IBB_V_Proj_Co2 są widokami. W rzeczywistości IBB_V_Proj_Co2 to widok 3-table, dokładnych danych brak ale postać:

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; 

Oznacza to, że widok IBB_V_Project ma zewnętrzny samosprzężenie na IBB_Project. Widok IBB_V_Post_Resp2 prawdopodobnie obejmował również 3 tabele (moje notatki na ten temat były nieco niejasne, w 1993 r., Kiedy zapisałem tę informację).

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; 

Kolumny Zzzz_Iref były albo seryjny lub INTEGER klucze obce przedstawieniu klucz seryjny.

Definicja widoku podstawowego odnosi się do 14 tabel, z 4 łączeniami wewnętrznymi i 9 łączeniami zewnętrznymi. Kiedy uwzględniane są widoki z odsyłaczami, to w sumie to 18 tabel z 7 wewnętrznymi łączeniami i 10 zewnętrznymi łączeniami.

Answer 9

będę po prostu odpowiedzieć z perspektywy najlepszych praktyk:

Istnieje tylko kilka razy by wstrzymać się z wykorzystaniem poglądów na widoki.

1. Zagnieżdżanie wydaje się wymykać spod kontroli ... jak ponad 3 poziomy głębokości. Powodem, dla którego się pakuję, jest ułatwienie utrzymania kodu. Jak tylko zacznę docierać do tego punktu, zaczynam czuć się trochę zbyt skomplikowanym, aby to zrozumieć.

2. Zagnieżdżanie widoku korzystającego z funkcji analitycznych. Osobiście, z tego czy innego powodu, nie miałem bardzo dobrych doświadczeń z zagnieżdżaniem widoków z funkcją analityczną.

3. Zagnieżdżanie widoków, które wykonują pełne skanowanie z natury.Chociaż myślę, że optymalizator zapytań jest prawdopodobnie wystarczająco inteligentny, aby sobie z tym poradzić, wydaje mi się, że jest mi źle, gdy przeglądam logikę widoku.

4. Wyniki są bardzo ważne. Nie oznacza to, że optymalizator może źle się pomylić, ale to znaczy, zanim go wypuszczę, przetestuję go, aby sprawdzić, czy nie mogę wymyślić szybszej metody.

Poza tym dość dobrze wykorzystałem widoki na widoki.

Answer 10

naprawdę nie chcą dać się wciągnąć w całej zagnieżdżonego widzenia rzeczy

mają o tym myśleć na pomysł ... Twój próbuje dołączyć na stole znaleźć niedopasowania ... użyłbym funkcja Oracle "minus" .... MINUS wybiera elementy z pierwszej tabeli, a następnie usuwa wiersze, które są również zwracane przez drugą instrukcję SELECT.

SELECT Num OD (SELECT 1 jako Lb od Podwójnej UNION ALL SELECT 2 jako Lb od Podwójnej UNION ALL SELECT 3 jako Lb od Podwójnej) base_view

minus

SELECT 2 AS num FROM DUAL