Widok z JOIN

Widok z JOIN zestawia dane z kilku tabel według zdefiniowanego warunku złączenia.

Czym widok jest po stronie serwera bazy danych

Widok nie przechowuje danych. To zapisana pod nazwą definicja zapytania SELECT, którą optymalizator w momencie użycia rozwija i łączy z zapytaniem odwołującym się do widoku. Polecenie CREATE VIEW w SQL Server musi być pierwszą instrukcją w partii, więc w skryptach poprzedza się je słowem GO. W definicji łączącej kilka tabel każda kolumna występująca w więcej niż jednej z nich wymaga aliasu — inaczej serwer zwróci błąd o niejednoznacznej nazwie kolumny.

Rodzaj złączenia decyduje o zawartości wyniku. INNER JOIN zwraca wyłącznie pary spełniające warunek ON, LEFT JOIN zachowuje wszystkie wiersze tabeli po lewej stronie i uzupełnia brakujące kolumny wartościami NULL. Dla raportu „klienci bez zamówień” to różnica między pustym zestawieniem a poprawnym.

Widok zwykły kontra widok indeksowany

Zwykły widok jest liczony przy każdym odwołaniu. Widok indeksowany, utworzony z klauzulą WITH SCHEMABINDING i unikalnym indeksem klastrowanym, materializuje wynik na dysku. Płaci się za to ograniczeniami: nie wolno użyć złączeń zewnętrznych, podzapytań ani zwykłego COUNT — dopuszczalny jest COUNT_BIG. Doliczyć trzeba też koszt aktualizacji przy każdym zapisie do tabel źródłowych, co przy dokumentach magazynowych bywa odczuwalne. Alternatywą bywa zwykłe zapytanie z CTE albo tabela pomocnicza odświeżana nocnym zadaniem Agenta.

Dlaczego zestawienie nagle zwalnia albo pokazuje złe liczby

Najczęstsza pułapka to warunek na kolumnie tabeli dołączonej przez LEFT JOIN umieszczony w sekcji WHERE zamiast w ON — takie zapytanie po cichu zachowuje się jak złączenie wewnętrzne i gubi wiersze. Druga to złączenie jeden-do-wielu przed agregacją: każda pozycja dokumentu powiela wiersz nagłówka i suma wartości zamówień wychodzi zawyżona. Widok zbudowany na SELECT * nie zauważa kolumny dodanej później do tabeli, dopóki nie wywoła się procedury sp_refreshview. Brak indeksu na kolumnie klucza obcego zamienia złączenie w pełny skan tabeli, co przy kilkuset tysiącach wierszy widać jako kilkunastosekundowe zawieszenie raportu.

Bazy Subiekta i WAPRO pod naszą opieką

Wdrażamy i serwisujemy oprogramowanie handlowe oparte o SQL Server — Subiekt, WAPRO i Comarch — więc trafiają do nas zgłoszenia typu „raport chodził, a teraz stoi”. Sprawdzamy wtedy plan wykonania, indeksy i statystyki, a przy uszkodzonej instancji zajmujemy się odtworzeniem bazy z kopii. Firmowy serwer możemy zabrać własnym transportem i odwieźć po naprawie, bez pośrednictwa kuriera.