Dlaczego tworzysz widok w bazie danych?

Między innymi może być używany dla bezpieczeństwa. Jeśli masz tabelę "klienta", możesz dać wszystkim sprzedawcom dostęp do nazwy, adresu, kodu pocztowego itp. pola, ale nie credit_card_number. Można utworzyć widok zawierający tylko te kolumny, do których mają dostęp, a następnie przyznać im dostęp w widoku.

Widok jest enkapsulacją zapytania. Zapytania, które są przekształcane w widoki, wydają się być skomplikowane i jako takie zapisywanie ich jako widoku do ponownego użycia może być korzystne.

Zazwyczaj tworzę widoki w celu de-normalizacji i / lub agregacji danych często używanych do celów raportowania.

EDIT

W drodze opracowania, gdybym miał mieć bazę danych, w której niektóre z podmiotów to osoba, firma, rola, Typ właściciela, zamówienie, szczegóły zamówienia, adres i telefon, w której tabela osób przechowywała zarówno pracowników i kontakty, a tabele adresowe i telefoniczne przechowywał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 innym programistom), takich jak sprzedaż przez pracownika lub sprzedaż przez Klienta lub sprzedaż według regionu, sprzedaż według miesiąca, Klienci według stanu itp. Chciałbym stworzyć zestaw widoków, które de-znormalizowały relacje między podmiotami bazodanowymi, tak aby bardziej zintegrowany widok (nie zamierzony kalambur) podmiotów świata rzeczywistego był dostępny. Niektóre z korzyści mogą obejmować:

1. redukcja redundancji w zapytaniach pisarskich
2. ustanowienie normy dla podmiotów powiązanych
3. zapewnienie możliwości oceniaj i Maksymalizuj wydajność do skomplikowanych obliczeń i połączeń (np. indeksowanie widoków Schemabound w MSSQL)
[[9]}uczynienie danych bardziej dostępnymi i intuicyjny dla członków zespołu i nie-programistów.

Kilka powodów: Jeśli masz skomplikowane połączenia, czasami najlepiej jest mieć widok tak, że każdy dostęp będzie zawsze mieć połączenia poprawne i deweloperzy don; t muszą pamiętać wszystkie tabele mogą potrzebować. Zazwyczaj może to dotyczyć aplikacji finansowej, w której niezwykle ważne byłoby, aby wszystkie sprawozdania finansowe były oparte na tym samym zestawie danych.

Jeśli masz użytkowników, którzy chcą ograniczyć liczbę rekordów, które mogą kiedykolwiek zobaczyć, możesz użyć widoku, dać im dostęp tylko do wyświetlanie nie bazowych tabel, a następnie odpytywanie widoku

Crystal reports wydaje się preferować używanie widoków do przechowywanych proc, więc ludzie, którzy robią dużo pisania raportów, mają tendencję do używania wielu widoków

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

Jedną z głównych zalet widoku nad procedurą składowaną jest to, że możesz używać widoku tak samo, jak używasz tabeli. Mianowicie, Widok może być odwołany bezpośrednio w klauzuli FROM zapytania. Np. SELECT * FROM dbo.name_of_view.

W prawie każdy inny sposób, procedury przechowywane są bardziej wydajne. Można przekazać parametry, w tym parametry out, które pozwalają skutecznie zwracać kilka wartości naraz, można zrobić SELECT, INSERT, UPDATE, i DELETE operacje itp. itd.

If you want a View ' s możliwość odpytywania z klauzuli FROM, ale chcesz również przekazać parametry, jest na to sposób. Nazywa się to funkcją o wartości tabelarycznej.

Oto bardzo przydatny artykuł na ten temat:

Http://databases.aspfaq.com/database/should-i-use-a-view-a-stored-procedure-or-a-user-defined-function.html{[18]

EDIT: przy okazji, tego rodzaju nasuwa się pytanie, jaką przewagę ma widok nad funkcją o wartości tabelkowej? Nie wiem. mam na to naprawdę dobrą odpowiedź, ale zauważę, że składnia T-SQL do tworzenia widoku jest prostsza niż dla funkcji o wartości tabelkowej, a użytkownicy Twojej bazy danych mogą być bardziej zaznajomieni z widokami.

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

Przykład:

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

Jednak większość systemu, jeśli chodzi o osobę, nadal używała pewnych rzeczy jako jednej rzeczy, niewiele rzeczy. Użyliśmy widoku, aby połączyć wszystkie niektóre z nich i umieścić go w widok, który ładnie wyszedł.

Zadziałało to, ponieważ warstwa danych uległa zmianie, ale wymagania biznesowe nie zmieniły się zasadniczo, więc obiekty biznesowe nie musiały się zmieniać. Gdyby obiekty biznesowe musiały się zmienić, nie sądzę, by było to realne rozwiązanie, ale widoki zdecydowanie funkcjonują jako dobry punkt środkowy.

Oto dwa wspólne powody:

Możesz go użyć dla bezpieczeństwa. Nie przyznawaj żadnych uprawnień do tabeli głównej i twórz widoki ograniczające dostęp do kolumn lub wierszy, a także przyznawaj uprawnienia użytkownikom do wyświetlania widoku.

Możesz użyć użyj go dla wygody. Połącz ze sobą tabele, których używasz razem przez cały czas w widoku. Może to sprawić, że zapytania będą spójne i łatwiejsze.

Jest więcej niż jeden powód, aby to zrobić. Czasami sprawia, że zwykłe zapytania join są łatwe, ponieważ można po prostu odpytywać nazwę tabeli zamiast wykonywać wszystkie połączenia.

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

Table1: Colums-USER_ID;USERNAME; SSN

Administratorzy mogą mieć privs na rzeczywistej tabeli, ale użytkownicy, do których nie chcesz mieć dostępu, mówią SSN, tworzysz Widok jako

CREATE VIEW USERNAMES AS SELECT user_id, username FROM Table1;

Następnie dać im dostęp do widoku i Nie stół.

Widoki mogą być darem niebios podczas raportowania w starszych bazach danych. W szczególności można używać sensownych nazw tabel zamiast kryptograficznych nazw 5 liter (gdzie 2 z nich są wspólnym prefiksem!), lub nazwy kolumn pełne skrótów, które na pewno miały wtedy sens.

Generalnie używam widoków, aby ułatwić życie, uzyskać rozszerzone szczegóły od jakiegoś podmiotu, który jest przechowywany w wielu tabelach (eliminuje wiele złączeń w kodzie, aby zwiększyć czytelność), a czasami dzielę się danymi w wielu bazach danych lub nawet aby wstawiania były łatwiejsze do odczytania.

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

Aby skupić się na konkretnych danych Widoki pozwalają użytkownikom skupić się na konkretnych danych, które ich interesują i na konkretnych zadaniach, za które są odpowiedzialni. Niepotrzebne dane można pominąć w widoku. Zwiększa to również bezpieczeństwo danych, ponieważ użytkownicy mogą zobaczyć tylko dane zdefiniowane w widoku, a nie DANE w tabeli bazowej. 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 Danych Manipulacja Widoki mogą uprościć sposób manipulowania danymi przez użytkowników. Często używane zapytania złączenia, projekcje, zapytania złączenia i zapytania SELECT można definiować jako widoki, dzięki czemu użytkownicy nie muszą określać wszystkich warunków i kwalifikacji za każdym razem, gdy wykonywana jest dodatkowa operacja na tych danych. Na przykład złożone zapytanie, które jest używane do celów raportowania i wykonuje zapytania podrzędne, 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ż podstawowe zapytanie nie musi być pisane lub przesyłane za każdym razem, gdy raport jest generowany; zamiast tego Widok jest zapytywany. Więcej informacji na temat manipulowania danymi.

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

Aby Dostosować Dane Widoki pozwalają różnym użytkownikom na zobacz dane na różne sposoby, nawet jeśli jednocześnie używają tych samych danych. Jest to szczególnie korzystne, gdy użytkownicy o wielu 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 handluje 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 eksport danych do innych aplikacji. Na przykład możesz użyć tabel sklepów i sprzedaży w bazie danych pubs do analizy danych sprzedaży za pomocą programu Microsoft ® Excel. W tym celu można utworzyć widok oparty na sklepach i tabelach sprzedaży. Następnie można użyć narzędzia bcp do wyeksportowania danych zdefiniowanych przez Widok. Dane mogą być również importowane do niektórych widoków z plików danych za pomocą instrukcji BCP utility lub BULK INSERT, pod warunkiem że wiersze mogą być wstawiane do widoku za pomocą instrukcji INSERT. Na więcej informacji na temat ograniczeń kopiowania danych do widoków, patrz INSERT. Aby uzyskać więcej informacji na temat używania instrukcji BCP utility and BULK INSERT do kopiowania danych do i z widoku, Zobacz kopiowanie do i z widoku.

Aby Połączyć Partycjonowane Dane Operator Transact-SQL UNION set może być używany w widoku do łączenia wyników dwóch lub więcej zapytań z oddzielnych tabel w jeden zestaw wyników. Dla użytkownika jest to pojedyncza tabela zwana partycjonowanym widokiem. Na na przykład, jeśli jedna tabela zawiera dane dotyczące sprzedaży dla Waszyngtonu, a inna tabela zawiera dane dotyczące sprzedaży Dla Kalifornii, można utworzyć widok z połączenia tych tabel. Widok przedstawia dane sprzedaży dla obu regionów. Aby korzystać z 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. Gdy widok jest pytany, SQL Server automatycznie określa, które tabele dotyczy zapytania i odwołuje się tylko do tych tabel. Na przykład, jeśli zapytanie określa, że wymagane są tylko dane sprzedaży dla stanu Waszyngton, SQL Server odczytuje tylko tabelę zawierającą dane Sprzedaży Waszyngtonu; nie są dostępne żadne inne tabele.

Partycjonowane widoki 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 serwerów zdalnych, z których każdy przechowuje dane dla w innym regionie organizacji można tworzyć rozproszone zapytania, które pobierają dane z każdego źródła danych, a następnie tworzyć widok na podstawie tych rozproszonych zapytań. Wszelkie zapytania odczytują tylko dane z tabel na serwerach zdalnych, które zawierają dane żądane przez zapytanie; inne serwery, do których odnoszą się rozproszone zapytania w widoku, nie są dostępne.

Gdy partycjonujesz dane w wielu tabelach lub na wielu serwerach, zapytania uzyskują dostęp do tylko ułamka danych może działać szybciej, ponieważ jest mniej danych do skanowania. Jeśli tabele znajdują się na różnych serwerach lub na komputerze z wieloma procesorami, każda tabela zaangażowana w zapytanie może być również skanowana równolegle, co poprawia wydajność zapytania. Ponadto zadania konserwacyjne, takie jak przebudowa indeksów lub tworzenie kopii zapasowych tabeli, mogą być wykonywane szybciej. Korzystając z widoku podzielonego na partycje, dane nadal pojawiają się jako pojedyncza tabela i mogą być zapytywane jako takie bez konieczności odwoływania się do poprawnego podkład tabeli ręcznie.

Partycjonowane widoki można aktualizować, jeśli którykolwiek z tych warunków jest spełniony: Zamiast wyzwalacza zdefiniowano w widoku logikę obsługującą polecenia INSERT, UPDATE I DELETE.

Zarówno Widok, jak i instrukcje INSERT, UPDATE I DELETE są zgodne z regułami zdefiniowanymi dla uaktualnialnych widoków podzielonych na partycje. Aby uzyskać więcej informacji, zobacz Tworzenie partycji Widok.

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

Kiedy chcę zobaczyć migawkę tabeli lub / i widok (w sposób tylko do odczytu)

Lubię używać widoków nad procedurami składowanymi, gdy uruchamiam tylko zapytanie. Widoki mogą również uprościć zabezpieczenia, ułatwiać wstawianie / aktualizowanie wielu tabel oraz tworzyć migawki/zmaterializować dane (uruchamiać długotrwałe zapytania i przechowywać wyniki w pamięci podręcznej).

Użyłem zmaterializowanych widoków dla zapytań run longing, które nie są wymagane, aby były dokładne w czasie rzeczywistym.

Widoki rozkładają również bardzo złożoną konfigurację i tabele na łatwe do zarządzania kawałki, które można łatwo odpytywać. 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ć zmaterializowane poglądy . Moje doświadczenie jest głównie z Oracle {[4] } ale podobno SQL-Server jest dość podobny.

Użyliśmy czegoś podobnego w naszej architekturze, aby rozwiązać problemy z wydajnością XML. Nasze systemy są zaprojektowane z dużą ilością danych przechowywanych jako XML w wierszu i aplikacje mogą wymagać zapytań o określone wartości w nim. Obsługa wielu typów Xmltypów i uruchamianie ścieżek XPath w dużych liczba 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 za każdym razem, gdy tabela bazowa się zmieni. 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ę składowaną bardziej jako metodę, którą mogę wywołać na podstawie moich danych, podczas gdy dla mnie widok zapewnia mechanizm tworzenia syntetycznej wersji danych bazowych, na podstawie której można tworzyć zapytania lub procedury składowane. Stworzę Widok, gdy uproszczenie lub agregacja ma sens. Napiszę procedurę składowaną, gdy chcę zapewnić bardzo konkretną usługę.

Ciekawostką dotyczącą widoków jest to, że są one postrzegane przez Microsoft Access jako tabele: gdy dołączasz interfejs Microsoft Access do bazy danych SQL przy użyciu ODBC, widzisz tabele i widoki na liście dostępnych tabel. Jeśli więc przygotowujesz skomplikowane raporty w MS Access, możesz pozwolić serwerowi SQL na łączenie i odpytywanie, a także znacznie uprościć swoje życie. Również do przygotowania zapytania w MS Excel.

Mam tylko 10 lub tak wyświetleń w moich bazach produkcyjnych. Używam kilku kolumn używam cały czas. Jeden zestaw, którego używam pochodzą z 7 tabel, niektóre z zewnętrznymi połączeniami i zamiast przepisywać, że stale muszę tylko wywołać ten widok w select i zrobić jedno lub 2 połączenia. Dla mnie to tylko oszczędność czasu.

Tworzę xxx, który odwzorowuje wszystkie relacje między tabelą główną (Jak tabela produktów) i tabelami referencyjnymi (jak ProductType lub ProductDescriptionByLanguage). Stworzy to widok, który pozwoli mi pobrać produkt i wszystkie jego szczegóły przetłumaczone z jego kluczy obcych do jego opisu. Następnie mogę użyć ORM do tworzenia obiektów do łatwego budowania siatek, pól combo itp.

Pomyśl o tym jako o refaktoryzacji schematu bazy danych.

Myślę, że pierwszy .aby ukryć złożoność zapytania. Jest bardzo odpowiedni dla poglądów .Jak przy normalizacji tabel bazy danych wzrasta.Teraz pobieranie danych jest bardzo trudne, gdy liczba tabel increases.So najlepszym sposobem obsługi jest obserwowanie widoków.Jeśli się mylę popraw mnie.

Tworzymy widok w celu ograniczenia lub ograniczenia dostępu do wszystkich wierszy / kolumn w tabeli.Jeśli właściciel chce, aby tylko określone lub ograniczone wiersze/kolumny były współdzielone, wtedy utworzy widok z tymi kolumnami.