Modyfikacja procedury składowanej

Modyfikacja procedury składowanej poleceniem ALTER PROCEDURE zmienia jej treść bez utraty przypisanych uprawnień.

Rola procedury składowanej w bazie danych

Procedura składowana jest nazwanym obiektem zapisanym w bazie danych. Zawiera instrukcje wykonywane po jej wywołaniu, na przykład zapytania odczytujące dane, operacje modyfikujące rekordy, warunki, zmienne lokalne oraz obsługę błędów. Aplikacja może korzystać z procedury bez przesyłania za każdym razem całego zestawu instrukcji SQL. Dzięki temu logika określonej operacji znajduje się w jednym miejscu, a zmiana tej logiki może być przeprowadzona przez modyfikację obiektu bazodanowego.

Modyfikacja procedury składowanej nie oznacza utworzenia całkowicie nowego obiektu. W silnikach obsługujących polecenie ALTER PROCEDURE zmienia się definicję istniejącej procedury wskazanej nazwą, schematem lub innym identyfikatorem wymaganym przez dany system. Zachowanie uprawnień zależy od silnika i rodzaju zmiany, jednak samo polecenie ALTER jest przeznaczone do zmiany istniejącego obiektu, a nie do jego usunięcia i ponownego utworzenia. Dlatego modyfikacja może zachować przypisane uprawnienia, podczas gdy procedura usunięta poleceniem DROP i utworzona ponownie wymagałaby odtworzenia konfiguracji dostępu.

Przebieg zmiany definicji przez ALTER PROCEDURE

Przed wykonaniem modyfikacji należy odczytać aktualną definicję procedury i ustalić jej pełny interfejs. Istotne są przede wszystkim nazwa obiektu, schemat, parametry wejściowe, typy danych, wartości domyślne oraz sposób zwracania wyników. Zmiana nazwy parametru, jego typu albo wymaganej obecności może spowodować błędy w aplikacji, która wywołuje procedurę według wcześniejszego kontraktu. Równie ważne jest sprawdzenie tabel, widoków, funkcji i innych procedur używanych wewnątrz modyfikowanego kodu.

Instrukcja ALTER PROCEDURE zwykle zawiera nową treść procedury oraz jej parametry. Silnik analizuje składnię i zapisuje zmienioną definicję, jeżeli polecenie przejdzie walidację. Sama poprawność składni nie potwierdza jednak poprawności działania. Procedura może odwoływać się do kolumn, których nie ma w tabeli, zwracać inny zestaw kolumn niż oczekuje aplikacja albo wykonywać operacje w niewłaściwej kolejności. W praktyce zmianę należy wykonać w kontrolowanym środowisku, z zachowaniem poprzedniej definicji umożliwiającej porównanie i ewentualne odtworzenie kodu.

Uprawnienia, zależności i skutki wykonania

Modyfikacja procedury wpływa na kod wykonywany pod jej nazwą, ale nie powinna być utożsamiana ze zmianą danych przechowywanych w tabelach. Dane zostaną zmienione dopiero wtedy, gdy nowa treść procedury zawiera instrukcje takie jak INSERT, UPDATE lub DELETE i zostanie wywołana w warunkach pozwalających na ich wykonanie. Jeżeli procedura wykonuje operacje w ramach transakcji, znaczenie ma również sposób zatwierdzania lub wycofywania transakcji oraz reakcja na błąd w części instrukcji.

Ważnym elementem jest model uprawnień. Użytkownik może mieć prawo do wywoływania procedury, ale nie mieć bezpośredniego prawa do odczytu lub zmiany tabel wykorzystywanych przez jej kod. Z kolei osoba modyfikująca definicję potrzebuje uprawnienia administracyjnego lub właścicielskiego wymaganego przez konkretny silnik. Zmiana treści może również wpłynąć na plan wykonania zapytań, zależnie od mechanizmu optymalizacji i kompilacji stosowanego przez bazę. Po modyfikacji należy sprawdzić czas wykonania, liczbę zwracanych wierszy, blokady oraz zachowanie przy pustych i nietypowych danych wejściowych.

Nie każda zależność jest widoczna w samej definicji procedury. Aplikacja może oczekiwać określonych nazw kolumn, kolejności wyników, kodów błędów albo komunikatów zwracanych przez procedurę. Z tego powodu zmiana wewnętrznego zapytania może być bezpieczna, natomiast zmiana parametrów lub struktury wyniku może wymagać modyfikacji kodu aplikacji. Szczególnej kontroli wymagają procedury wywoływane przez inne procedury, zadania automatyczne i moduły programu działające bez bezpośredniej obsługi użytkownika.

Weryfikacja zmodyfikowanej procedury

Po zapisaniu nowej definicji należy przeprowadzić testy odpowiadające rzeczywistym sposobom użycia procedury. Trzeba sprawdzić poprawne parametry, wartości graniczne, brak wyników, wielokrotne wywołanie oraz sytuacje, w których część danych jest niekompletna. Jeżeli procedura zapisuje dane, test powinien obejmować także kontrolę liczby zmienionych rekordów i skutków ubocznych w tabelach powiązanych relacjami lub wyzwalaczami. Nie należy ograniczać weryfikacji do jednego przykładowego rekordu.

Warto porównać wynik przed i po zmianie, o ile celem modyfikacji nie jest właśnie zmiana zachowania. Porównanie powinno obejmować wartości, typy danych, kolejność kolumn oraz sposób obsługi błędów. Należy również wykonać test wywołania z konta, które ma używać procedury w normalnej pracy, ponieważ osoba zmieniająca definicję może posiadać szersze uprawnienia niż aplikacja. Taki test pozwala wykryć problemy z autoryzacją, zależnościami obiektów i kontekstem wykonania.

W środowisku, w którym procedura obsługuje dane użytkowe, zaleca się zachowanie informacji o dacie zmiany, autorze, poprzedniej i nowej definicji oraz wyniku testów. Dokumentowanie nie zastępuje testu, ale ułatwia ustalenie, która wersja kodu była aktywna podczas wystąpienia problemu. Jeżeli modyfikacja powoduje błędy aplikacji, należy najpierw porównać parametry i strukturę wyniku, a następnie sprawdzić zależności oraz wykonanie zapytań. Diagnostyka komputera lub laptopa może obejmować analizę konfiguracji programu bazodanowego i połączenia z aplikacją, natomiast sama procedura jest obiektem zarządzanym wewnątrz konkretnego silnika bazy danych.