Procedura z kursorem

Procedura z kursorem przetwarza wiersze pojedynczo — rozwiązanie wolniejsze niż operacje zbiorowe, stosowane gdy logika tego wymaga.

Procedura z kursorem – czym jest i do czego służy

Procedura z kursorem to sposób wykonywania operacji na danych, w którym kolejne wiersze wyniku są pobierane i obsługiwane pojedynczo. Najpierw przygotowuje się zbiór danych, następnie otwiera się kursor, pobiera bieżący wiersz, wykonuje przypisaną mu logikę i przechodzi do następnego elementu. Po przetworzeniu całego zbioru kursor zostaje zamknięty, a zasoby używane podczas pracy są zwalniane. Takie rozwiązanie przypomina ręczne przechodzenie po uporządkowanej liście, z możliwością podjęcia innej decyzji dla każdego elementu.

W praktyce procedura z kursorem bywa stosowana wtedy, gdy każda obserwacja wymaga osobnego działania, a wynik poprzedniego kroku wpływa na następny. Może chodzić o zapisanie informacji w kilku tabelach, utworzenie komunikatu zależnego od wartości konkretnego rekordu, sprawdzenie warunku biznesowego albo wykonanie operacji, której nie da się wygodnie opisać jednym poleceniem działającym na całym zbiorze. Kursor nie jest więc samodzielnym rodzajem danych, lecz mechanizmem kontrolowania kolejności odczytu i przetwarzania wierszy.

Podczas projektowania takiej procedury należy określić zapytanie źródłowe, kolejność pobierania danych, sposób obsługi bieżącego wiersza, reakcję na brak wyników oraz działania wykonywane po zakończeniu pętli. Warto również ustalić, co ma się wydarzyć po wystąpieniu błędu. Bez takiego planu łatwo doprowadzić do pozostawienia otwartego kursora, częściowego przetworzenia danych albo trudnego do wykrycia powtarzania tej samej operacji.

Procedura z kursorem na tle operacji zbiorowych i pętli

Najważniejsza różnica między procedurą z kursorem a operacją zbiorową dotyczy sposobu pracy z danymi. Operacja zbiorowa opisuje rezultat dla całego zestawu, a system bazodanowy może samodzielnie dobrać sposób wykonania polecenia. Przy kursorze jawnie wskazuje się, że trzeba przejść przez kolejne wiersze. Daje to większą kontrolę nad przebiegiem logiki, ale nakłada również obowiązek zarządzania stanem procedury.

W podejściu zbiorowym można na przykład zmienić wartości w wielu rekordach za pomocą jednego polecenia opartego na warunku. Przy kursorze dla każdego rekordu może zostać uruchomiony osobny fragment kodu. Taki model jest czytelny, gdy decyzja dotycząca jednego wiersza musi zostać zapisana, przekazana do kolejnego kroku albo połączona z czynnością wykonywaną poza samym zapytaniem. Jeżeli jednak wszystkie rekordy mają zostać zmodyfikowane według tej samej reguły, operacja zbiorowa zwykle prowadzi do prostszego kodu i mniejszego narzutu.

Procedura z kursorem różni się także od zwykłej pętli wykonywanej w języku programowania. Kursor utrzymuje kontekst zapytania i wskazuje aktualne miejsce w wyniku, natomiast pętla może działać na tablicy, kolekcji, strumieniu lub innym obiekcie przygotowanym przez aplikację. Wybór zależy od tego, gdzie znajduje się logika. Przenoszenie całego wyniku do aplikacji może zwiększyć zużycie pamięci i ruch między komponentami, a pozostawienie całości w bazie może utrudnić wykorzystanie gotowych mechanizmów aplikacyjnych.

Przy porównaniu kilku rozwiązań powinno się uwzględnić liczbę wierszy, złożoność warunku, konieczność zachowania kolejności, wpływ blokad oraz częstotliwość uruchamiania procedury. Sama obecność kursora nie przesądza jeszcze o błędnym projekcie. Problem pojawia się wtedy, gdy używa się go do czynności, które bez utraty znaczenia można wykonać zbiorowo.

Procedura z kursorem a typowe problemy wykonania

Jednym z częstych problemów jest tak zwane przetwarzanie wiersz po wierszu bez potrzeby. Każde pobranie rekordu i każda osobna operacja wiąże się z dodatkową obsługą. Przy małym zbiorze może nie być to odczuwalne, ale przy rosnącej liczbie danych czas wykonania zaczyna zależeć nie tylko od samego zapytania, lecz także od liczby przejść przez pętlę. Z tego powodu przed użyciem kursora powinno się sprawdzić, czy nie da się wyrazić tej samej reguły za pomocą łączenia tabel, warunku, funkcji okna, agregacji lub innego polecenia zbiorowego.

Kolejnym zagrożeniem jest nieprawidłowa obsługa cyklu życia kursora. Otwarcie powinno być poprzedzone przygotowaniem danych, a po zakończeniu należy wykonać pobranie ostatniego wiersza, zamknąć kursor i zwolnić zasoby. W przypadku błędu potrzebna jest ścieżka porządkowania, która zamknie aktywne obiekty niezależnie od miejsca przerwania. Pominięcie tego etapu może prowadzić do zajmowania zasobów przez dłuższy czas, blokowania innych operacji albo niejasnych błędów przy kolejnym uruchomieniu.

Trudności może powodować również zmiana danych podczas przechodzenia po wyniku. Jeżeli procedura modyfikuje tabelę, z której jednocześnie pobiera rekordy, trzeba uwzględnić zachowanie używanego mechanizmu, izolację transakcji oraz możliwość pominięcia lub ponownego odczytania wiersza. Znaczenie ma także kolejność wyników. Bez jawnego uporządkowania nie powinno się zakładać, że rekordy zostaną zwrócone w określonej sekwencji.

Warto kontrolować obsługę wartości pustych, nieoczekiwanych typów danych i rekordów niespełniających założeń. Przydatne bywa rejestrowanie identyfikatora aktualnego wiersza, etapu procedury oraz informacji o błędzie. Należy jednak ograniczać ilość zapisywanych komunikatów, aby diagnostyka sama nie stała się głównym obciążeniem.

Procedura z kursorem – praktyczne wskazówki projektowe

Przed napisaniem procedury powinno się opisać regułę w języku operacyjnym: jakie rekordy są wybierane, jakie działanie wykonuje się dla każdego z nich, jakie warunki kończą pracę i co zostaje zapisane po sukcesie. Następnie można przygotować wariant zbiorowy i wariant kursorowy, a później porównać ich czytelność, zachowanie w transakcji oraz czas wykonania. Taki test pomaga uniknąć sytuacji, w której kursor zostaje użyty tylko dlatego, że jego konstrukcja wydaje się intuicyjna.

Zapytanie źródłowe powinno zwracać wyłącznie kolumny potrzebne do wykonania logiki. Ograniczenie zbędnych danych zmniejsza ilość pracy podczas pobierania i ułatwia późniejszą analizę. Warunki wyboru najlepiej stosować możliwie wcześnie, aby pętla nie przechodziła przez rekordy, które i tak zostaną pominięte. Gdy kolejność ma znaczenie, należy określić ją wprost i oprzeć na stabilnym kryterium.

Przetwarzanie warto dzielić na krótkie, zrozumiałe etapy. Dobrze jest oddzielić pobranie danych od walidacji, właściwego działania i zapisu wyniku. Ułatwia to testowanie oraz wskazanie miejsca, w którym wystąpił problem. Jeżeli pojedynczy rekord może powodować błąd, należy ustalić, czy cała transakcja ma zostać wycofana, czy błąd ma zostać odnotowany i procedura ma przejść dalej. Decyzja powinna wynikać ze znaczenia danych, a nie wyłącznie z wygody implementacji.

Podczas testów powinno się sprawdzić pusty wynik, pojedynczy rekord, wiele rekordów, powtarzające się wartości, wartości puste, rekord zmieniony w trakcie działania oraz przerwanie procedury. Należy również ocenić zachowanie po ponownym uruchomieniu. Dobrze zaprojektowana procedura powinna jasno określać, czy ponowne wykonanie jest bezpieczne, czy wymaga oznaczenia wcześniej obsłużonych wierszy.

Procedura z kursorem – kiedy zgłosić się do serwisu

Problemy z procedurą z kursorem mogą wynikać nie tylko z samego kodu. Przyczyną bywa niewłaściwa konfiguracja środowiska, uszkodzenie nośnika, niestabilna pamięć, błędy systemu operacyjnego, przerwane aktualizacje albo problemy z połączeniem między aplikacją i bazą danych. Objawami wymagającymi sprawdzenia może być nagłe wydłużenie wykonywania, powtarzanie tych samych operacji, zatrzymywanie się na konkretnym rekordzie, niepełny zapis danych lub komunikat o braku zasobów.

Przed przekazaniem sprzętu do sprawdzenia warto zanotować moment wystąpienia problemu, nazwę programu, rodzaj wykonywanej operacji oraz komunikat błędu. Nie powinno się wielokrotnie uruchamiać procedury na danych produkcyjnych, jeśli nie wiadomo, czy działanie jest powtarzalne i czy nie tworzy duplikatów. W miarę możliwości należy przygotować kopię zapasową oraz oddzielić problem z kodem od problemu ze sprzętem, na przykład przez porównanie zachowania na innym, bezpiecznym środowisku.

W Warszawie pomocą przy diagnostyce sprzętu i oprogramowania zajmuje się Warszawskie Pogotowie Komputerowe 24/7. Przy zgłoszeniu można przedstawić opis objawów, ekran komunikatu oraz informacje o ostatnich zmianach, aby ułatwić ustalenie, czy źródła problemu należy szukać w komputerze, systemie, połączeniu czy samej procedurze. W przypadku danych biznesowych należy wcześniej zabezpieczyć kopie i przekazać wyłącznie informacje potrzebne do przeprowadzenia analizy.