Dlaczego tworzysz widok w bazie danych?

Kiedy i dlaczego ktoś decyduje, że musi utworzyć widok w swojej bazie danych? Dlaczego po prostu nie uruchomić zwykłej procedury składowanej lub wybrać?

Widok zapewnia kilka korzyści.

1. Widoki mogą ukrywać złożoność

Jeśli masz zapytanie, które wymaga połączenia kilku tabel lub masz złożoną logikę lub obliczenia, możesz zakodować całą tę logikę w widoku, a następnie wybrać z widoku tak, jak w przypadku tabeli.

2. Widoki mogą służyć jako mechanizm bezpieczeństwa

Widok może wybrać określone kolumny i / lub wiersze z tabeli (lub tabel) oraz uprawnienia ustawione dla widoku zamiast tabel bazowych. Umożliwia to wyświetlanie tylko tych danych, które użytkownik musi zobaczyć.

3. Widoki mogą uprościć obsługę starszego kodu

Jeśli musisz zmienić tabelę, która złamałaby dużo kodu, możesz zastąpić tabelę widokiem o tej samej nazwie. Widok zapewnia dokładnie ten sam schemat co oryginalna tabela, podczas gdy rzeczywisty schemat się zmienił. Zapobiega to uszkodzeniu starszego kodu odwołującego się do tabeli, co pozwala na zmianę starszego kodu w dowolnym momencie.

To tylko niektóre z wielu przykładów przydatności widoków.

Między innymi może służyć do bezpieczeństwa. Jeśli masz tabelę „klient”, możesz dać wszystkim sprzedawcom dostęp do pól imienia i nazwiska, adresu, kodu pocztowego itp., Ale nie numeru karty kredytowej. Możesz utworzyć widok, który zawiera tylko kolumny, do których potrzebują dostępu, a następnie udzielić im dostępu do widoku.

Widok jest enkapsulacją zapytania. Zapytania przekształcane w widoki są zwykle skomplikowane, dlatego zapisanie ich jako widoku do ponownego wykorzystania może być korzystne.

Zwykle tworzę widoki w celu znormalizowania i / lub agregacji danych często wykorzystywanych do celów sprawozdawczych.

EDYTOWAĆ

Tytułem opracowania, gdybym miał bazę danych, w której niektóre podmioty byłyby osobami, firmą, rolą, typem właściciela, zamówieniem, szczegółami zamówienia, adresem i telefonem, w którym w tabeli osób przechowywane były zarówno pracownicy, jak i kontakty oraz adres i w tabelach telefonów przechowywane były numery telefonów zarówno dla osób, jak i firm, a zespół programistów miał za zadanie generowanie raportów (lub udostępnianie danych raportowania osobom niebędącym programistami), takich jak sprzedaż przez pracownika lub sprzedaż przez klienta lub sprzedaż według regionu, sprzedaż według miesiąca , klientów według stanu itp. Utworzyłbym zestaw widoków, który zdenormalizował relacje między jednostkami bazy danych, aby był dostępny bardziej zintegrowany widok (bez zamierzonej gry słów) rzeczywistych jednostek. Niektóre z korzyści mogą obejmować:

1. Zmniejszenie redundancji w pisaniu zapytań
2. Ustanowienie standardu dla powiązanych podmiotów
3. Zapewnienie możliwości oceny i maksymalizacji wydajności złożonych obliczeń i połączeń (np. Indeksowanie widoków schematów w MSSQL)
4. Uczynienie danych bardziej dostępnymi i intuicyjnymi dla członków zespołu i nie-programistów.

Kilka powodów: jeśli masz skomplikowane sprzężenia, czasami najlepiej jest mieć widok, aby każdy dostęp zawsze miał poprawne połączenia, a programiści nie muszą pamiętać wszystkich tabel, których mogą potrzebować. Zwykle może to dotyczyć aplikacji finansowej, w której niezwykle ważne jest, aby wszystkie raporty finansowe były oparte na tym samym zestawie danych.

Jeśli masz użytkowników, których chcesz ograniczyć liczbę rekordów, które mogą kiedykolwiek zobaczyć, możesz użyć widoku, dać im dostęp tylko do widoku, a nie do bazowych tabel, a następnie wysłać zapytanie do tego widoku

Wydaje się, że raporty Crystal wolą używać widoków niż przechowywanych procesów, więc ludzie, którzy dużo piszą, zwykle używają wielu widoków

Widoki są również bardzo przydatne podczas refaktoryzacji baz danych. Często można ukryć zmianę, aby stary kod jej nie widział, tworząc widok. Przeczytaj o refaktoryzacji baz danych, aby zobaczyć, jak to działa, ponieważ jest to bardzo skuteczny sposób na refaktoryzację.

Jedną z głównych zalet widoku w porównaniu z procedurą przechowywaną jest to, że można korzystać z widoku tak samo, jak z tabeli. Mianowicie do widoku można odwoływać się bezpośrednio w FROMklauzuli zapytania. Np SELECT * FROM dbo.name_of_view.

Prawie pod każdym innym względem procedury składowane są silniejsze. Można przekazać w parametrów, w tym outparametrów, które pozwalają skutecznie powrócić kilka wartości naraz, można to zrobić SELECT, INSERT, UPDATE, i DELETEoperacje, itd. Itd.

Jeśli chcesz, aby widok mógł wysyłać zapytania z poziomu FROMklauzuli, ale chcesz także przekazywać parametry, istnieje również sposób, aby to zrobić. Nazywa się to funkcją wycenioną w tabeli.

Oto całkiem przydatny artykuł na ten temat:

http://databases.aspfaq.com/database/should-i-use-a-view-a-stored-procedure-or-a-user-defined-function.html

EDYCJA: Nawiasem mówiąc, tego rodzaju pytanie nasuwa pytanie, jaką przewagę ma widok nad funkcją wycenianą w tabeli? Nie mam na to naprawdę dobrej odpowiedzi, ale zauważę, że składnia T-SQL do tworzenia widoku jest prostsza niż w przypadku funkcji o wartości tabeli, a użytkownicy twojej bazy danych mogą być bardziej zaznajomieni z widokami.

Może funkcjonować jako dobry „środkowy człowiek” między twoim ORM a twoimi stołami.

Przykład:

Mieliśmy tabelę Person, którą potrzebowaliśmy zmienić na niej strukturę, aby kolumna SomeColumn została przeniesiona do innej tabeli i miała relację jeden do wielu.

Jednak większość systemu, w odniesieniu do Osoby, nadal używała SomeColumn jako jednej rzeczy, a nie wielu rzeczy. Użyliśmy widoku, aby zebrać wszystkie SomeColumns razem i umieścić je w widoku, który dobrze się sprawdził.

Działało to, ponieważ zmieniono warstwę danych, ale wymagania biznesowe nie uległy zasadniczej zmianie, więc obiekty biznesowe nie musiały się zmieniać. Gdyby obiekty biznesowe musiały się zmienić, nie sądzę, że byłoby to realne rozwiązanie, ale widoki zdecydowanie działają jako dobry punkt środkowy.

Skoncentrowanie się na określonych widokach danych pozwala użytkownikom skupić się na konkretnych danych, które ich interesują, oraz na konkretnych zadaniach, za które są odpowiedzialni. Niepotrzebne dane można pominąć. Zwiększa to również bezpieczeństwo danych, ponieważ użytkownicy widzą tylko dane zdefiniowane w widoku, a nie dane w podstawowej tabeli. Aby uzyskać więcej informacji na temat używania widoków do celów bezpieczeństwa, zobacz Używanie widoków jako mechanizmów bezpieczeństwa.

Uproszczenie manipulacji danymi Widoki mogą uprościć sposób, w jaki użytkownicy manipulują danymi. Często definiowane połączenia, projekcje, zapytania UNION i zapytania SELECT można zdefiniować jako widoki, aby użytkownicy nie musieli określać wszystkich warunków i kwalifikacji za każdym razem, gdy na tych danych wykonywana jest dodatkowa operacja. Na przykład złożone zapytanie, które jest używane do celów raportowania i wykonuje podzapytania, połączenia zewnętrzne i agregację w celu pobrania danych z grupy tabel, można utworzyć jako widok. Widok upraszcza dostęp do danych, ponieważ bazowe zapytanie nie musi być zapisywane ani przesyłane przy każdym generowaniu raportu; zamiast tego wyświetla się widok. Aby uzyskać więcej informacji o manipulowaniu danymi.

Można również tworzyć wbudowane funkcje zdefiniowane przez użytkownika, które logicznie działają jako widoki sparametryzowane lub widoki, które mają parametry w warunkach wyszukiwania klauzuli WHERE. Aby uzyskać więcej informacji, zobacz Funkcje wbudowane zdefiniowane przez użytkownika.

Aby dostosować widoki danych, pozwól różnym użytkownikom zobaczyć dane na różne sposoby, nawet jeśli jednocześnie korzystają z tych samych danych. Jest to szczególnie korzystne, gdy użytkownicy o różnych zainteresowaniach i poziomach umiejętności korzystają z tej samej bazy danych. Na przykład można utworzyć widok, który pobiera tylko dane klientów, z którymi współpracuje menedżer konta. Widok może określić, które dane należy pobrać na podstawie identyfikatora logowania menedżera konta, który korzysta z widoku.

Aby eksportować i importować dane Widoki można wykorzystać do eksportowania danych do innych aplikacji. Na przykład możesz użyć sklepów i tabel sprzedaży w bazie danych pubów do analizy danych sprzedaży za pomocą Microsoft® Excel. Aby to zrobić, możesz utworzyć widok na podstawie sklepów i tabel sprzedaży. Następnie można użyć narzędzia bcp do wyeksportowania danych zdefiniowanych przez widok. Dane można również importować do niektórych widoków z plików danych za pomocą narzędzia bcp lub instrukcji BULK INSERT, pod warunkiem, że wiersze można wstawić do widoku za pomocą instrukcji INSERT. Aby uzyskać więcej informacji o ograniczeniach dotyczących kopiowania danych do widoków, zobacz WSTAW. Aby uzyskać więcej informacji na temat używania narzędzia bcp i instrukcji BULK INSERT do kopiowania danych do iz widoku, zobacz Kopiowanie do lub z widoku.

Aby połączyć dane podzielone na partycje Operatora zestawu Transact-SQL UNION można użyć w widoku, aby połączyć wyniki dwóch lub więcej zapytań z oddzielnych tabel w jeden zestaw wyników. Wygląda to na użytkownika jako pojedyncza tabela zwana widokiem podzielonym na partycje. Na przykład, jeśli jedna tabela zawiera dane sprzedaży dla Waszyngtonu, a inna tabela zawiera dane sprzedaży dla Kalifornii, można utworzyć widok z UNION tych tabel. Widok reprezentuje dane sprzedaży dla obu regionów. Aby użyć widoków podzielonych na partycje, należy utworzyć kilka identycznych tabel, określając ograniczenie określające zakres danych, które można dodać do każdej tabeli. Widok jest następnie tworzony przy użyciu tych tabel podstawowych. Po zapytaniu o widok SQL Server automatycznie określa, na które tabele ma wpływ zapytanie i odwołuje się tylko do tych tabel. Na przykład, jeśli zapytanie określa, że ​​wymagane są tylko dane dotyczące sprzedaży dla stanu Waszyngton, SQL Server odczytuje tylko tabelę zawierającą dane dotyczące sprzedaży w Waszyngtonie; nie są dostępne żadne inne tabele.

Widoki podzielone na partycje mogą być oparte na danych z wielu heterogenicznych źródeł, takich jak zdalne serwery, a nie tylko tabele w tej samej bazie danych. Na przykład, aby połączyć dane z różnych zdalnych serwerów, z których każdy przechowuje dane dla innego regionu organizacji, możesz utworzyć rozproszone zapytania, które pobierają dane z każdego źródła danych, a następnie utworzyć widok na podstawie tych rozproszonych zapytań. Wszelkie zapytania odczytują tylko dane z tabel na zdalnych serwerach, które zawierają dane żądane przez zapytanie; pozostałe serwery, do których odwołują się rozproszone zapytania w widoku, nie są dostępne.

Gdy dzielisz dane na wiele tabel lub wielu serwerów, zapytania uzyskujące dostęp tylko do części danych mogą być uruchamiane szybciej, ponieważ jest mniej danych do skanowania. Jeśli tabele znajdują się na różnych serwerach lub na komputerze z wieloma procesorami, każdą tabelę zaangażowaną w zapytanie można również skanować równolegle, co poprawia wydajność zapytania. Ponadto zadania konserwacyjne, takie jak odbudowywanie indeksów lub tworzenie kopii zapasowej tabeli, mogą być wykonywane szybciej. Korzystając z widoku podzielonego na partycje, dane nadal pojawiają się jako pojedyncza tabela i można je odpytywać jako takie bez konieczności ręcznego odwoływania się do właściwej tabeli podstawowej.

Widoki podzielone na partycje można aktualizować, jeśli spełniony jest jeden z następujących warunków: W widoku zdefiniowano wyzwalacz INSTEAD OF z logiką do obsługi instrukcji INSERT, UPDATE i DELETE.

Zarówno widok, jak i instrukcje INSERT, UPDATE i DELETE są zgodne z regułami zdefiniowanymi dla aktualizowanych widoków partycjonowanych. Aby uzyskać więcej informacji, zobacz Tworzenie widoku podzielonego na partycje.

https://technet.microsoft.com/en-us/library/aa214282(v=sql.80).aspx#sql:join

Oto dwa typowe powody:

Możesz go użyć dla bezpieczeństwa. Nie przyznawaj żadnych uprawnień do głównej tabeli i twórz widoki, które ograniczają dostęp do kolumny lub wiersza i udzielaj użytkownikom uprawnień do wyświetlania widoku.

Możesz użyć go dla wygody. Połącz ze sobą niektóre tabele, których używasz cały czas w widoku. Dzięki temu zapytania będą spójne i łatwiejsze.

Jest więcej niż jeden powód, aby to zrobić. Czasami sprawia, że ​​typowe zapytania dotyczące łączenia są łatwe, ponieważ wystarczy wykonać zapytanie o nazwę tabeli zamiast wykonywać wszystkie połączenia.

Innym powodem jest ograniczenie danych do różnych użytkowników. Na przykład:

Tabela 1: Kolumny - USER_ID; USERNAME; SSN

Użytkownicy administracyjni mogą mieć uprawnienia do rzeczywistej tabeli, ale użytkownicy, którzy nie chcą mieć dostępu do powiedzenia SSN, tworzą widok jako

UTWÓRZ WIDOK USERNAMES JAK WYBIERZ id_użytkownika, nazwa użytkownika z tabeli 1;

Następnie daj im uprawnienia dostępu do widoku, a nie do tabeli.

Widoki mogą być darem niebios przy raportowaniu starszych baz danych. W szczególności możesz używać sensownych nazw tabel zamiast tajemniczych 5-literowych nazw (gdzie 2 z nich to wspólny przedrostek!) Lub nazw kolumn pełnych skrótów, które z pewnością miały wtedy sens.

Zasadniczo korzystam z widoków, aby ułatwić życie, uzyskiwać rozszerzone szczegóły z jakiegoś elementu, który jest przechowywany w wielu tabelach (eliminuję wiele połączeń w kodzie, aby zwiększyć czytelność), a czasem dzielę dane w wielu bazach danych, a nawet ułatwiam czytanie wstawek.

Oto jak używać widoku wraz z uprawnieniami do ograniczania kolumn, które użytkownik może aktualizować w tabeli.

/* This creates the view, limiting user to only 2 columns from MyTestTable */
CREATE VIEW dbo.myTESTview 
WITH SCHEMABINDING AS
SELECT ID, Quantity FROM dbo.MyTestTable;

/* This uses the view to execute an update on the table MyTestTable */
UPDATE dbo.myTESTview
SET Quantity = 7
WHERE ID = 1

Kiedy chcę zobaczyć migawkę tabeli (tabel) i / lub widok (tylko do odczytu)

Lubię korzystać z widoków nad procedurami przechowywanymi, gdy uruchamiam tylko zapytanie. Widoki mogą również uprościć bezpieczeństwo, mogą być użyte do ułatwienia wstawiania / aktualizacji wielu tabel, a także mogą być używane do tworzenia migawek / materializacji danych (uruchamianie długotrwałego zapytania i przechowywanie wyników w pamięci podręcznej).

Użyłem zmaterializowanych widoków do wykonywania długich zapytań, które nie muszą być dokładne w czasie rzeczywistym.

Widoki dzielą również bardzo złożoną konfigurację i tabele na porcje, które można łatwo przeszukiwać. W naszej bazie danych cały nasz system zarządzania tabelami jest podzielony na widoki z jednej dużej tabeli.

To nie odpowiada dokładnie na twoje pytanie, ale pomyślałem, że warto wspomnieć o zmaterializowanych widokach . Moje doświadczenie jest głównie z Oracle ale podobno SQL-Server jest podobny.

W naszej architekturze zastosowaliśmy coś podobnego do rozwiązania problemów z wydajnością XML. Nasze systemy są zaprojektowane z dużą ilością danych przechowywanych jako XML w jednym rzędzie, a aplikacje mogą potrzebować zapytać o określone wartości w tym wierszu. Obsługa wielu typów XMLT i uruchamianie ścieżek XPath w dużej liczbie wierszy ma duży wpływ na wydajność, dlatego używamy formy zmaterializowanych widoków, aby wyodrębnić pożądane węzły XML do tabeli relacyjnej przy każdej zmianie tabeli podstawowej. To skutecznie zapewnia fizyczną migawkę zapytania w danym momencie, w przeciwieństwie do standardowych widoków, które uruchamiałyby zapytanie na żądanie.

Widzę procedurę przechowywaną bardziej jako metodę, którą mogę wywołać względem moich danych, podczas gdy dla mnie widok zapewnia mechanizm do tworzenia syntetycznej wersji danych podstawowych, na podstawie których można tworzyć zapytania lub procedury przechowywane. Stworzę widok, gdy uproszczenie lub agregacja ma sens. Napiszę procedurę składowaną, gdy chcę zapewnić bardzo konkretną usługę.

Ciekawą rzeczą związaną z widokami jest to, że są one postrzegane przez Microsoft Access jako tabele: kiedy dołączasz interfejs Microsoft Access do bazy danych SQL za pomocą ODBC, widzisz tabele i widoki na liście dostępnych tabel. Więc jeśli przygotowujesz skomplikowane raporty w MS Access, możesz pozwolić serwerowi SQL na łączenie i zapytania, a także znacznie uprościć swoje życie. To samo dotyczy przygotowania zapytania w MS Excel.

Mam tylko 10 widoków w moich produkcyjnych bazach danych. Używam kilku kolumn, których używam cały czas. Jeden zestaw, którego używam, pochodzi z 7 tabel, niektóre z zewnętrznymi złączeniami i zamiast przepisywać, że ciągle muszę tylko wywoływać ten widok w zaznaczeniu i wykonać jedno lub dwa łączenia. Dla mnie to tylko oszczędność czasu.

Tworzę xxx, który odwzorowuje wszystkie relacje między tabelą główną (jak tabela produktów) a tabelami referencyjnymi (takimi jak ProductType lub ProductDescriptionByLanguage). Spowoduje to utworzenie widoku, który pozwoli mi pobrać produkt i wszystkie jego szczegóły przetłumaczone z jego kluczy obcych na opis. Następnie mogę użyć ORM do tworzenia obiektów, aby łatwo budować siatki, pola kombi itp.

Potraktuj to jako refaktoryzację schematu bazy danych.

Myślę, że pierwszy. Aby ukryć złożoność zapytania. Jest to bardzo odpowiednie dla widoków .Jak normalizujemy wzrosty tabel w bazie danych. Pobieranie danych jest bardzo trudne, gdy liczba tabel wzrasta. Tak więc najlepszym sposobem na obsługę jest śledzenie widoków. Jeśli się mylę, popraw mnie.

Tworzymy widok, aby ograniczyć dostęp do wszystkich wierszy / kolumn w tabeli. Jeśli właściciel chce, aby udostępniać tylko określone lub ograniczone wiersze / kolumny, utworzy widok z tą kolumną.

Dla bezpieczeństwa: daje każdemu użytkownikowi uprawnienia dostępu do bazy danych tylko za pośrednictwem małego zestawu widoków, które zawierają określone dane, które użytkownik lub grupa użytkowników może zobaczyć, ograniczając dostęp użytkownika do innych danych.

Prostota zapytań i struktury : widok może rysować dane z kilku tabel i prezentować pojedynczą tabelę, upraszczając informacje i przekształcając zapytania z wielu tabel w zapytania z jedną tabelą dla widoku i dając użytkownikom określony widok struktury bazy danych, prezentując baza danych jako zestaw wirtualnych tabel specyficznych dla konkretnych użytkowników lub grup użytkowników.

Aby utworzyć spójną strukturę bazy danych : Widoki przedstawiają spójny, niezmieniony obraz struktury bazy danych, nawet jeśli podstawowe tabele źródłowe zostaną zmienione.