Do czego służą widoki?

Próbuję tylko uzyskać ogólne pojęcie o tym, do czego służą widoki w RDBMS. To znaczy, wiem, czym jest widok i jak go stworzyć. Wiem też, do czego ich używałem w przeszłości.

Ale chcę się upewnić, że dokładnie rozumiem, do czego widok jest przydatny, a do czego nie powinien. Dokładniej:

1. Do czego służy widok?
   • Czy są sytuacje, w których kuszące jest użycie widoku, którego nie należy używać?
   • Dlaczego miałbyś używać widoku zamiast czegoś takiego jak funkcja o wartościach tabelarycznych lub odwrotnie?
   • Czy są jakieś okoliczności, w których widok może być przydatny, a które nie są widoczne na pierwszy rzut oka?

(Dla przypomnienia, niektóre z tych pytań są celowo naiwne. Po części jest to weryfikacja koncepcji).

1) Do czego służy widok?

IOPO tylko w jednym miejscu

• Niezależnie od tego, czy rozważasz same dane, czy zapytania odwołujące się do połączonych tabel, wykorzystanie widoku pozwala uniknąć niepotrzebnej nadmiarowości.

• Widoki zapewniają również warstwę abstrakcji uniemożliwiającą bezpośredni dostęp do tabel (i wynikające z tego kajdanki odwołujące się do fizycznych zależności). W rzeczywistości uważam, że dobrą praktyką ¹ jest oferowanie tylko abstrakcyjnego dostępu do danych bazowych (przy użyciu widoków i funkcji wycenianych w tabeli), w tym widoków takich jak ¹ Muszę przyznać, że jest dużo „Rób tak, jak mówię; nie tak, jak ja zrobić "w tej radzie;)

CREATE VIEW AS
      SELECT * FROM tblData

2) Czy są sytuacje, w których kuszące jest użycie widoku, którego nie należy używać?

Kiedyś problemem była wydajność w kontekście łączenia (np. SQL 2000). Nie jestem ekspertem, ale od jakiegoś czasu się tym nie martwię. (Nie mogę też myśleć o tym, gdzie obecnie używam połączeń widoków).

Inną sytuacją, w której widok może być przesadzony, jest sytuacja, w której odwołanie do widoku jest tylko z jednej wywołującej lokalizacji i zamiast tego można użyć tabeli pochodnej. Podobnie jak typ anonimowy jest lepszy od klasy w .NET, jeśli typ anonimowy jest używany / przywoływany tylko raz.

    • Zobacz opis tabeli pochodnej w http://msdn.microsoft.com/en-us/library/ms177634.aspx

3) Dlaczego miałbyś używać widoku zamiast czegoś takiego jak funkcja o wartościach tabelarycznych lub odwrotnie?

(Oprócz powodów związanych z wydajnością) Funkcja wyceniana w tabeli jest funkcjonalnym odpowiednikiem sparametryzowanego widoku. W rzeczywistości typowym przypadkiem użycia funkcji wycenianej w tabeli jest po prostu dodanie filtru klauzuli WHERE do już istniejącego widoku w pojedynczym obiekcie.

4) Czy są jakieś okoliczności, w których widok może być przydatny, a które nie są widoczne na pierwszy rzut oka?

Nie przychodzą mi do głowy żadne niewidoczne zastosowania czubka głowy. (Myślę, że gdybym mógł, to by je ujawniło;)

W pewnym sensie widok jest jak interfejs. Możesz zmienić podstawową strukturę tabeli, ile chcesz, ale widok pozwala na to, aby kod nie musiał się zmieniać.

Widoki to dobry sposób na dostarczenie autorom raportów czegoś prostego. Jeśli użytkownicy biznesowi chcą uzyskać dostęp do danych z czegoś takiego jak Crystal Reports, możesz udostępnić im widoki na swoim koncie, które upraszczają dane - może nawet je denormalizują.

Widoki mogą być używane do zapewniania bezpieczeństwa (tj .: użytkownicy mogą mieć dostęp do widoków, które mają dostęp tylko do niektórych kolumn w tabeli), widoki mogą zapewniać dodatkowe zabezpieczenia aktualizacji, wstawień itp. Widoki umożliwiają również aliasowanie nazw kolumn (podobnie jak sp), ale widoki są bardziej izolacją od rzeczywistej tabeli.

W pewnym sensie poglądy ulegają denormalizacji. Czasami konieczna jest denormalizacja, aby dane były bardziej zrozumiałe. To właśnie robi wiele aplikacji w ramach modelowania domeny w swoich obiektach. Pomagają prezentować dane w sposób bardziej zbliżony do perspektywy biznesowej.

Oprócz tego, co stwierdzili inni, widoki mogą być również przydatne do usuwania bardziej skomplikowanych zapytań SQL z aplikacji.

Na przykład zamiast w aplikacji:

sql = "wybierz a, b z tabeli1 union wybierz a, b z tabeli2";

Możesz to streścić w widoku:

utwórz widok union_table1_table2_v jako
wybierz a, b z tabeli1
union
wybierz a, b z tabeli2

aw kodzie aplikacji wystarczy:

sql = "wybierz a, b z union_table1_table2_v";

Ponadto, jeśli kiedykolwiek zmienią się struktury danych, nie będziesz musiał zmieniać kodu aplikacji, ponownie kompilować i ponownie wdrażać. po prostu zmieniłbyś widok w bazie danych.

Widoki ukrywają złożoność bazy danych. Są świetne z wielu powodów i są przydatne w wielu sytuacjach, ale jeśli masz użytkowników, którzy mogą pisać własne zapytania i raporty, możesz ich użyć jako zabezpieczenia, aby upewnić się, że nie przesyłają źle zaprojektowanych zapytania z paskudnymi złączeniami kartezjańskimi, które wyłączają serwer bazy danych.

OP zapytał, czy zdarzały się sytuacje, w których kuszące byłoby użycie widoku, ale nie jest to właściwe.

To, czego nie chcesz używać widoku, jest substytutem złożonych sprzężeń. Oznacza to, że nie pozwól, aby nawyk programowania proceduralnego polegający na rozkładaniu problemu na mniejsze części prowadził Cię do korzystania z kilku połączonych widoków zamiast jednego większego sprzężenia. Spowoduje to zniszczenie wydajności silnika bazy danych, ponieważ zasadniczo wykonuje on kilka oddzielnych zapytań, a nie jedno większe.

Na przykład, powiedzmy, że musisz połączyć tabele A, B, C i D. Możesz pokusić się o zrobienie widoku z tabel A i B oraz widoku z C & D, a następnie połącz oba widoki razem. O wiele lepiej jest po prostu dołączyć A, B, C i D w jednym zapytaniu.

Widoki mogą centralizować lub konsolidować dane. Tam, gdzie jestem, mamy wiele różnych baz danych na kilku różnych połączonych serwerach. Każda baza danych zawiera dane dla innej aplikacji. Kilka z tych baz danych zawiera informacje, które są powiązane z wieloma różnymi aplikacjami. W takich okolicznościach utworzymy widok w bazie danych tej aplikacji, który po prostu pobiera dane z bazy danych, w której dane są naprawdę przechowywane, tak aby zapytania, które piszemy, nie wyglądały tak, jakby przechodziły przez różne bazy danych.

Dotychczasowe odpowiedzi są poprawne - widoki są dobre dla zapewnienia bezpieczeństwa, denormalizacji (chociaż jest dużo bólu na tej drodze, jeśli zostaną zrobione źle), abstrakcji modelu danych itp.

Ponadto widoki są powszechnie używane do implementacji logiki biznesowej (wygasły użytkownik to użytkownik, który nie logował się w ciągu ostatnich 40 dni, tego typu rzeczy).

Widoki zapisują wiele powtarzających się złożonych instrukcji JOIN w skryptach SQL. Możesz po prostu hermetyzować skomplikowane JOIN w jakimś widoku i wywoływać je w instrukcji SELECT w razie potrzeby. Czasami byłoby to przydatne, proste i łatwiejsze niż zapisywanie instrukcji złączenia w każdym zapytaniu.

Widok to po prostu przechowywana, nazwana instrukcja SELECT. Pomyśl o widokach jak o funkcjach bibliotecznych.

Chciałem podkreślić użycie widoków do raportowania. Często występuje konflikt między normalizowaniem tabel bazy danych w celu przyspieszenia wydajności, szczególnie w przypadku edycji i wstawiania danych (użycie OLTP), a denormalizacją w celu zmniejszenia liczby sprzężeń tabel dla zapytań do raportowania i analizy (zastosowania OLAP). Z konieczności OLTP zwykle wygrywa, ponieważ wprowadzanie danych musi mieć optymalną wydajność. Tworzenie widoków, w celu uzyskania optymalnej wydajności raportowania, może zatem pomóc zadowolić obie klasy użytkowników (wprowadzanie danych i przeglądarki raportów).

Pamiętam bardzo długi WYBÓR, który obejmował kilka UNII. Każdy UNION zawierał dołączenie do tabeli cen, która została utworzona w locie przez SELECT, który sam był dość długi i trudny do zrozumienia. Myślę, że dobrym pomysłem byłoby mieć pogląd na to, aby stworzyć tabelę cen. Skróciłoby to ogólny wybór o około połowę.

Nie wiem, czy baza danych oceni widok raz, czy za każdym razem, gdy został wywołany. Ktoś wie? W pierwszym przypadku użycie widoku poprawiłoby wydajność.

Zawsze, gdy potrzebujesz [my_interface]! = [User_interface].

Przykład:

TABELA A:

• ID
• info

WIDOK dla TABELI A:

• Informacje dla klientów

w ten sposób możesz ukryć identyfikator przed klientem i jednocześnie zmienić nazwę informacji na bardziej szczegółową.

Widok użyje indeksu bazowego dla identyfikatora klucza podstawowego, więc nie zobaczysz utraty wydajności, a jedynie lepszą abstrakcję zapytania wybierającego.