Widok z TOP

Widok z TOP zwraca ograniczoną liczbę wierszy zgodnie z zadanym limitem.

Po co ktoś umieszcza TOP w definicji widoku

W Microsoft SQL Server widok nie może domyślnie zawierać klauzuli ORDER BY, bo z definicji jest zbiorem nieuporządkowanym. Przez lata obchodzono to ograniczenie sztuczką: dopisaniem TOP z bardzo dużą liczbą wierszy albo TOP 100 PERCENT, co formalnie legalizowało sortowanie w zapytaniu. Osobnym, sensowniejszym zastosowaniem jest widok celowo ograniczający wynik, na przykład zwracający dziesięć ostatnich zamówień albo pierwszy tysiąc rekordów do podglądu w aplikacji raportowej. Składniowo TOP przyjmuje liczbę wierszy lub procent, a z modyfikatorem WITH TIES dołącza dodatkowe wiersze o takiej samej wartości sortowania jak ostatni zakwalifikowany.

TOP, ORDER BY i OFFSET FETCH

Sedno problemu polega na tym, że optymalizator traktuje sortowanie wewnątrz widoku jako wskazówkę służącą wybraniu wierszy, a nie jako obietnicę kolejności w wyniku końcowym. Zapytanie SELECT z takiego widoku bez własnego ORDER BY może zwrócić rekordy w dowolnym porządku i porządek ten potrafi zmienić się po dodaniu indeksu, po aktualizacji statystyk albo po zwykłym przyroście danych. Nowocześniejszym i czytelniejszym rozwiązaniem stronicowania jest OFFSET wraz z FETCH NEXT, wymagające jawnego ORDER BY w zapytaniu. Praktyczna zasada brzmi: kolejność ustala się tam, gdzie odczytuje się dane, a nie w warstwie widoku.

Widok z TOP jako źródło niepowtarzalnych wyników

Typowy scenariusz awarii: raport przez rok pokazywał dane w oczekiwanej kolejności, po czym po migracji na nowszy serwer zaczął losowo przestawiać wiersze, choć nikt nie zmieniał zapytania. Drugi kłopot to stronicowanie w aplikacji, w którym ten sam rekord pojawia się na dwóch stronach, a inny nie pojawia się wcale, bo kryterium sortowania nie jest jednoznaczne i nie zawiera unikalnej kolumny. Trzeci to widok z TOP nałożony na kolejny widok, przez co ograniczenie stosuje się na innym etapie, niż spodziewał się autor. Wydajnościowo widok z dużym TOP bywa też przeszkodą przy zwijaniu zapytań przez optymalizator.

Aplikacja bazodanowa, która zaczyna zwalniać

Nie każdy wolny raport ma swoje źródło w zapytaniu. Programy handlowe i magazynowe potrafią spowolnić przez zapełniony dysk systemowy, brak pamięci na serwerze, przeciążone łącze do stanowisk albo dysk talerzowy pracujący z błędami. Warszawskie Pogotowie Komputerowe sprawdza takie stanowiska od strony sprzętowej i systemowej: mierzy czasy dostępu do nośnika, weryfikuje pamięć, porządkuje kopie bazy i konfigurację sieci lokalnej w biurze. Obsługujemy firmy siedem dni w tygodniu, o dowolnej porze, a na czas naprawy udostępniamy laptopa zastępczego.