Kiedy używać widoku zamiast tabeli?

Kiedy w rzeczywistości należy używać widoku nad rzeczywistą tabelą? Jakich korzyści powinienem się spodziewać?

Jakie są ogólnie zalety korzystania z widoku nad stołem? Czy nie powinienem w pierwszej kolejności zaprojektować stołu tak, jak powinien wyglądać widok?

Och, jest wiele różnic, które musisz wziąć pod uwagę

Widoki do wyboru:

1. Widoki zapewniają abstrakcję nad tabelami. Możesz łatwo dodawać / usuwać pola w widoku bez modyfikowania podstawowego schematu
2. Widoki mogą łatwo modelować złożone połączenia.
3. Widoki mogą ukrywać przed Tobą rzeczy specyficzne dla bazy danych. Np. Jeśli potrzebujesz sprawdzić kilka rzeczy używając funkcji SYS_CONTEXT Oracles lub wielu innych rzeczy
4. Możesz łatwo zarządzać dotacjami bezpośrednio w widokach, a nie w rzeczywistych tabelach. Łatwiej jest zarządzać, jeśli wiesz, że określony użytkownik może uzyskać dostęp tylko do widoku.
5. Widoki mogą pomóc w uzyskaniu zgodności wstecznej. Możesz zmienić podstawowy schemat, ale widoki mogą ukryć te fakty przed określonym klientem.

Widoki do wstawienia / aktualizacji:

1. Problemy związane z bezpieczeństwem widoków można rozwiązać, korzystając z takich funkcji, jak klauzula Oracle „WITH CHECK OPTION” bezpośrednio w widoku

Wady

1. Utracisz informacje o relacjach (klucze podstawowe, klucze obce)
2. Nie jest oczywiste, czy będziesz w stanie wstawić / zaktualizować widok, ponieważ widok ukrywa przed Tobą podstawowe sprzężenia

Widoki mogą:

• Uprość złożoną strukturę tabeli
• Uprość swój model bezpieczeństwa, umożliwiając filtrowanie poufnych danych i przypisywanie uprawnień w prostszy sposób
• Umożliwiają zmianę logiki i zachowania bez zmiany struktury wyjściowej (wyjście pozostaje takie samo, ale podstawowa funkcja SELECT może się znacznie zmienić)
• Zwiększ wydajność (widoki indeksowane serwera SQL)
• Oferuj optymalizację określonych zapytań z widokiem, który w przeciwnym razie może być trudny do uzyskania

I nie powinieneś projektować tabel tak, aby pasowały do ​​widoków . Twój model podstawowy powinien zajmować się wydajnym przechowywaniem i odzyskiwaniem danych. Widoki są częściowo narzędziem, które łagodzi złożoność wynikającą z wydajnego, znormalizowanego modelu, umożliwiając abstrakcję tej złożoności.

Również pytanie „jakie są zalety korzystania z widoku nad stołem?” Nie jest dobrym porównaniem. Nie możesz obejść się bez tabel, ale możesz obejść się bez widoków. Każdy z nich istnieje z zupełnie innego powodu. Tabele są konkretnym modelem, a widoki są abstrakcyjnym widokiem.

Widoki są akceptowalne, gdy trzeba mieć pewność, że za każdym razem jest stosowana złożona logika. Na przykład mamy widok, który tworzy surowe dane potrzebne do wszystkich sprawozdań finansowych. Dzięki temu, że wszystkie raporty korzystają z tego widoku, wszyscy pracują na tym samym zestawie danych, a nie w jednym raporcie używającym jednego zestawu sprzężeń, a innym zapominając o użyciu takiego, który daje różne wyniki.

Widoki są dopuszczalne, gdy chcesz ograniczyć użytkowników do określonego podzbioru danych. Na przykład, jeśli nie usuniesz rekordów, a tylko oznaczysz bieżący jako aktywny, a starsze wersje jako nieaktywne, chcesz, aby widok był używany do wybierania tylko aktywnych rekordów. Zapobiega to zapomnieniu umieszczenia klauzuli where w zapytaniu i uzyskaniu złych wyników.

Widoki mogą służyć do upewnienia się, że użytkownicy mają dostęp tylko do zestawu rekordów - na przykład widok tabel dla określonego klienta i brak praw zabezpieczeń w tabelach może oznaczać, że użytkownicy tego klienta mogą tylko wyświetlać dane dla tego klienta.

Widoki są bardzo pomocne podczas refaktoryzacji baz danych.

Widoki nie są akceptowane, gdy używasz widoków do wywoływania widoków, co może skutkować straszną wydajnością (przynajmniej w SQL Server). Prawie straciliśmy klienta wartego wiele milionów dolarów, ponieważ ktoś zdecydował się tak wyodrębnić bazę danych, a wydajność była przerażająca i często dochodziło do przekroczenia limitów czasu. Za naprawę musieliśmy zapłacić, a nie klient, ponieważ problem z wydajnością był całkowicie naszą winą. Gdy widoki wywołują widoki, muszą całkowicie wygenerować widok bazowy. Widziałem to, gdy widok nazywa się widokiem, który nazywa się widokiem i wygenerowano tak wiele milionów rekordów, aby zobaczyć trzy ostatecznie potrzebne użytkownikowi. Pamiętam, że w przypadku jednego z tych widoków wykonanie prostego policzenia (*) rekordów zajęło 8 minut. Poglądy wywołujące widoki to bardzo kiepski pomysł.

Widoki są często złym pomysłem do aktualizowania rekordów, ponieważ zwykle można aktualizować tylko pola z tej samej tabeli (znowu jest to SQL Server, inne bazy danych mogą się różnić). W takim przypadku bardziej sensowne jest bezpośrednie aktualizowanie tabel, aby wiedzieć, które pola są dostępne.

Widoki są przydatne, gdy musisz wybrać jedną z kilku tabel lub po prostu uzyskać podzbiór tabeli.

Tabele należy projektować w taki sposób, aby baza danych była dobrze znormalizowana (minimalne powielanie). Może to utrudniać wykonywanie zapytań.

Widoki są nieco oddzielone, co pozwala wyświetlać dane w tabelach inaczej niż są one przechowywane.

Powszechną praktyką jest ukrywanie sprzężeń w celu przedstawienia użytkownikowi bardziej zdenormalizowanego modelu danych. Inne zastosowania obejmują bezpieczeństwo (na przykład przez ukrycie niektórych kolumn i / lub wierszy) lub wydajność (w przypadku zmaterializowanych widoków)

Zaprojektuj swój stół BEZ rozważania widoków.
Oprócz zapisywania złączeń i warunków, Widoki mają również przewagę wydajnościową: SQL Server może obliczyć i zapisać swój plan wykonania w widoku, dzięki czemu jest szybszy niż instrukcje SQL „w locie”.
Widok może również ułatwić pracę związaną z dostępem użytkowników na poziomie pola.

Przede wszystkim, jak sama nazwa wskazuje, widok jest niezmienny. Dzieje się tak, ponieważ widok jest niczym innym jak wirtualną tabelą utworzoną z zapytania przechowywanego w bazie danych. Z tego powodu masz pewne cechy widoków:

• możesz wyświetlić tylko podzbiór danych
• możesz połączyć wiele tabel w jeden widok
• możesz agregować dane w widoku (wybierz liczbę)
• W rzeczywistości nie przechowują danych, nie potrzebują przestrzeni tabel, ponieważ są wirtualnymi agregacjami bazowych tabel

więc istnieje miliard przypadków użycia, w których widoki są lepiej dopasowane niż tabele, wystarczy pomyśleć o wyświetlaniu tylko aktywnych użytkowników w witrynie. widok byłby lepszy, ponieważ operujesz tylko na podzbiorze danych, które faktycznie znajdują się w Twojej bazie danych (aktywni i nieaktywni użytkownicy)

sprawdź ten artykuł

mam nadzieję, że to pomogło ...

Według Wikipedii ,

Widoki mają wiele zalet w porównaniu z tabelami:

• Widoki mogą reprezentować podzbiór danych zawartych w tabeli.

• Widoki mogą ograniczać stopień ekspozycji tabel bazowych na świat zewnętrzny: dany użytkownik może mieć uprawnienia do wysyłania zapytań do widoku, podczas gdy odmowa dostępu do reszty tabeli podstawowej.

• Widoki mogą łączyć i upraszczać wiele tabel w jedną wirtualną tabelę.

• Widoki mogą pełnić rolę tabel zagregowanych , w których silnik bazy danych agreguje dane (suma, średnia itp.) I przedstawia obliczone wyniki jako część danych.

• Widoki mogą ukrywać złożoność danych. Na przykład widok może wyglądać jak Sales2000 lub Sales2001, w sposób przezroczysty partycjonujący rzeczywistą tabelę bazową.

• Przechowywanie widoków zajmuje bardzo mało miejsca ; baza danych zawiera tylko definicję widoku, a nie kopię wszystkich danych, które przedstawia.

• Widoki mogą zapewnić dodatkowe bezpieczeństwo , w zależności od używanego silnika SQL.