Czy widoki bazy danych wpływają na wydajność zapytań?

Question

Czy widoki baz danych są jedynie sposobem na uproszczenie dostępu do danych lub czy zapewniają korzyści wydajnościowe podczas uzyskiwania dostępu do widoków, a nie tylko do uruchamiania kwerendy, na której oparty jest widok? Podejrzeń, które podejrzenia są funkcjonalnie równoważne tylko dodanie kwerendy przechowywanego widoku do każdego kwerendy na dane widoku, czy jest to poprawne, czy są inne szczegóły i/lub optymalizacje?

Answer 1

To zależy od RDBMS, ale zwykle nie ma optymalizacji, a to tylko wygodny sposób na uproszczenie zapytań. Niektóre systemy baz danych używają jednak "zmaterializowanych widoków", które wykorzystują mechanizm buforowania.

Answer 2

Zwykle widok jest po prostu sposobem na stworzenie wspólnego skrótu do definiowania zestawów wyników, których często potrzebujesz.

Jednak ma swoją wadę. Pokusa polega na dodawaniu w każdej kolumnie, którą według ciebie możesz potrzebować gdzieś, kiedy chcesz skorzystać z widoku. Więc YAGNI jest naruszone. Nie tylko kolumny, ale czasami dodatkowe sprzężenia zewnętrzne są łączone "na wszelki wypadek". Tak więc indeksy pokrywające mogą już nie obejmować, a plan kwerend może zwiększyć złożoność (i spadek wydajności).

YAGNI to krytyczna koncepcja w projektowaniu SQL.

Answer 3

Zawsze uważałem, że Widoki są jak Procedury przechowywane tylko do odczytu. Dajesz bazy danych jak najwięcej informacji z wyprzedzeniem, aby mogła ona wstępnie skompilować wszystko, co możliwe.

Można również wyświetlać widoki indeksu, co pozwala uzyskać dostęp do zoptymalizowanego widoku danych, których szukasz, dla danego typu zapytania.

Answer 4

Ogólnie rzecz biorąc, widoki powinny działać w sposób równoważny z zapytaniem zapisanym bezpośrednio w tabelach podstawowych.

Ale: mogą występować przypadki krańcowe i należy wypróbować kod. Wszystkie nowoczesne systemy RDBMS mają narzędzia, które umożliwiają wyświetlanie planów kwerend i monitorowanie wykonania. Nie bierz mi za to mojego (lub cudzego) słowa, kiedy możesz mieć ostateczne dane na wyciągnięcie ręki.

Answer 5

Mimo że pewne zapytanie uruchomione w widoku i to samo zapytanie działające poza widokiem powinno działać równorzędnie, rzeczy stają się znacznie bardziej skomplikowane, gdy trzeba połączyć dwa widoki razem. Możesz łatwo zakończyć przynosząc tabele, których nie potrzebujesz do zapytania lub przynosząc tabele w redundancji. Optymalizator bazy danych może mieć więcej problemów z tworzeniem dobrego planu wykonywania zapytań. Podczas gdy poglądy mogą być bardzo dobre pod względem dopuszczenia bardziej drobnoziarnistych zabezpieczeń i tym podobnych, niekoniecznie są dobre dla modułowości.

Answer 6

Wiem, że to stary wątek. Dyskusja jest dobra, ale chcę rzucić jeszcze jedną myśl. Wydajność zależy również od tego, czego używasz do pobierania danych. Na przykład, jeśli kończysz z czymś takim jak Microsoft Access, możesz zdecydowanie zwiększyć wydajność niektórych złożonych zapytań za pomocą widoku. Dzieje się tak dlatego, że program Access nie zawsze pobiera dane z serwera SQL, tak jak byśmy chcieli - w niektórych przypadkach przyciągałby całe tabele, a następnie próbowałby stamtąd przetwarzać lokalnie! Nie, jeśli używasz widoku.

Answer 7

Tak, we wszystkich nowoczesnych programach RDBMS (MSSQL po 2005 r. Itd.) Plany zapytań widoku są buforowane, co eliminuje obciążenie związane z planowaniem kwerendy i przyspiesza działanie w stosunku do tego samego SQL wykonywanego w trybie on-line. Poprzednio (i dotyczy to również sparametryzowanych instrukcji SQL/Przygotowanych), ludzie prawidłowo myśleli, że procedury przechowywane lepiej działały.

Wiele wciąż pozostaje na ten temat, czyniąc go nowoczesnym mottem DB. Od czasu, gdy widoki/PS otrzymały buforowane planowanie zapytań o SP, były prawie równe.