Czytam Biblię SQL Server 2008 i omawiam sekcję dotyczącą widoków. Ale autor tak naprawdę nie wyjaśnia celu poglądów. Jaki jest dobry użytek z widoków? Czy powinienem ich używać w swojej witrynie i jakie są z nich korzyści?
Odpowiedzi:
Innym zastosowaniem, o którym nie ma mowy w żadnej z poprzednich odpowiedzi, jest łatwiejsze wdrażanie zmian struktury tabeli.
Powiedzmy, że chcesz wycofać tabelę ( T_OLD) zawierającą dane aktywnych użytkowników i zamiast tego użyć nowej tabeli z podobnymi danymi (nazwanymi T_NEW), ale zawierającej dane zarówno dla aktywnych, jak i nieaktywnych użytkowników, z jedną dodatkową kolumną active.
Jeśli Twój system (y) mają miliardy zapytań, które to umożliwiają SELECT whatever FROM T_OLD WHERE whatever, masz dwie możliwości wdrożenia:
1) Cold Turkey - Zmień DB, a jednocześnie zmień, przetestuj i wypuść wiele fragmentów kodu, które zawierały wspomniane zapytanie. BARDZO trudne do zrobienia (a nawet koordynowania), bardzo ryzykowne. Zły.
2) Stopniowo - zmień bazę danych, tworząc T_NEWtabelę, usuwając T_OLDtabelę i zamiast tego tworząc WIDOK o nazwie, T_OLDktóry naśladuje T_OLDtabelę w 100% (np. Zapytanie widoku jest SELECT all_fields_except_active FROM T_NEW WHERE active=1).
Pozwoliłoby to uniknąć wydawania DOWOLNEGO kodu, który aktualnie wybiera z T_OLD, i wprowadzanie zmian w celu migracji kodu z T_OLDdo T_NEWw wolnym czasie.
To jest prosty przykład, są inne o wiele bardziej zaangażowane.
PS Z drugiej strony, prawdopodobnie powinieneś mieć API procedury składowanej zamiast bezpośrednich zapytań z T_OLD, ale nie zawsze tak jest.
(Skopiowane z pierwszego samouczka, który pojawił się w wyszukiwarce Google (link nie działa), ale ma wszystkie zalety, które sam bym wpisał ręcznie.)
Widoki mają następujące zalety:
- Bezpieczeństwo - widoki można udostępniać użytkownikom, podczas gdy podstawowe tabele nie są bezpośrednio dostępne. Dzięki temu administrator może udostępniać użytkownikom tylko te dane, których potrzebują, jednocześnie chroniąc inne dane w tej samej tabeli.
- Prostota - widoki mogą służyć do ukrywania i ponownego wykorzystywania złożonych zapytań.
- Uproszczenie lub wyjaśnienie nazw kolumn - Widoki mogą służyć do podawania aliasów nazw kolumn, aby były łatwiejsze do zapamiętania i / lub znaczące.
- Odskocznia - widoki mogą stanowić odskocznię w zapytaniu „wielopoziomowym”. Na przykład możesz utworzyć widok zapytania zliczającego liczbę transakcji sprzedaży dokonanych przez każdego ze sprzedawców. Następnie możesz wysłać zapytanie do tego widoku, aby pogrupować sprzedawców według liczby zrealizowanych transakcji sprzedaży.
Kilka powodów z Wikipedii :
Widoki mogą zapewnić przewagę nad tabelami:
VIEWS mogą być używane jako sekcje SELECT / CODE wielokrotnego użytku, które mogą być dołączane do innych selekcji / zapytań, które mają być połączone, i używać różnych różnych filtrów bez konieczności ponownego tworzenia całego SELECT za każdym razem.
To również umieszcza logikę w jednym miejscu, dzięki czemu nie trzeba jej zmieniać w całej bazie kodu.
Spójrz na
Wybór między procedurami składowanymi, funkcjami, widokami, wyzwalaczami, wbudowanym kodem SQL
Główne piękno widoku polega na tym, że w większości sytuacji można go używać jako tabeli, ale w przeciwieństwie do tabeli może zawierać bardzo złożone obliczenia i powszechnie używane łączenia. Może również używać praktycznie dowolnego obiektu w bazie danych, z wyjątkiem procedur składowanych. Widoki są najbardziej przydatne, gdy zawsze musisz łączyć się z tym samym zestawem tabel, powiedz zamówienie ze szczegółami zamówienia, aby uzyskać podsumowanie pól obliczeniowych itp.
Widok jest warstwą abstrakcji i robi to, co robi każda dobra warstwa abstrakcji, włączając w to hermetyzację schematu bazy danych i ochronę przed konsekwencjami zmiany wewnętrznych szczegółów implementacji.
To interfejs.
Oto jedno bardzo powszechne użycie widoków do ograniczenia jednostki według pewnych kryteriów.
Tabela: USERS zawiera wszystkich użytkowników
Widok: ACTIVE_USERS zawiera wszystkich użytkowników z wyłączeniem tych, którzy są zawieszeni, zbanowani, czekają na aktywację i nie spełniają żadnych kryteriów, które możesz zdefiniować w przyszłości w ramach aktywnych wymagań. Dzięki temu nie trzeba usuwać żadnych wierszy z tabeli USERS, jeśli zdecydujesz się tego nie robić, ponieważ ACTIVE_USERS zawsze może ukryć niechciane wiersze.
W ten sposób możesz używać tabeli na stronach zarządzania użytkownikami, ale reszta aplikacji może używać ACTIVE_USERS, ponieważ mogą być jedynymi użytkownikami, którzy powinni mieć możliwość wykonywania procesów i dostępu do danych / modyfikowania ich.
Widoki umożliwiają łączenie danych z kilku różnych tabel i formatowanie ich (łączenie pól, nadawanie bardziej znaczących nazw pól itp.), Aby ułatwić użytkownikom końcowym. Stanowią abstrakcję modelu bazy danych. Można ich również użyć, aby zapewnić użytkownikom dostęp do danych w tabeli bez bezpośredniego dostępu do samej tabeli.
Oto kilka z wielu powodów używania widoku zamiast bezpośrednio tabeli
Widoki są złe! Unikaj ich, jeśli to możliwe, i używaj tylko z powodu wskazanego przez DVK - tymczasowej migracji danych.
Należy zrozumieć, że w bazie danych zawierającej 100 tabel trudno jest zapamiętać przeznaczenie każdej tabeli. Teraz, jeśli dodasz tutaj kolejne 300 widoków, będzie to kompletny bałagan. Niż „Miłośnicy widoków” zwykle używają widoków zagnieżdżonych, a następnie używają widoków zagnieżdżonych w procedurach składowanych. Osobiście pracuję teraz z bazą danych, w której są 4 razy zagnieżdżone widoki! Aby zrozumieć najprostszą logikę procedury składowanej, muszę najpierw przejść przez wszystkie widoki.