Usuwanie widoku

Usuwanie widoku poleceniem DROP VIEW kasuje zapisane zapytanie bez wpływu na leżące pod nim tabele.

Usuwanie widoku w modelu relacyjnej bazy danych

Widok jest nazwanym obiektem bazy danych, którego definicja opisuje sposób pobierania danych. Zwykle zawiera zapytanie SELECT wskazujące kolumny, źródłowe tabele, połączenia między nimi, warunki filtrowania albo operacje agregujące. Sam widok najczęściej nie przechowuje niezależnej kopii wszystkich wyników. Przy odczycie silnik interpretuje jego definicję i wykorzystuje dane znajdujące się w obiektach źródłowych. Polecenie DROP VIEW usuwa z bazy właśnie taki obiekt definicyjny.

Usunięcie widoku nie jest tym samym co usunięcie danych. Wiersze pozostają w tabelach, a inne widoki i zapytania korzystające bezpośrednio z tych tabel nadal mogą działać. Znika natomiast nazwa widoku, jego definicja oraz możliwość odwołania się do niego w kolejnych instrukcjach. Próba wykonania SELECT z użyciem usuniętej nazwy zakończy się błędem informującym, że wskazany obiekt nie istnieje albo nie może zostać znaleziony w bieżącym schemacie.

Operacja zmienia strukturę bazy, dlatego wymaga odpowiednich uprawnień. Dokładny zakres wymaganych praw zależy od konkretnego silnika SQL, schematu i sposobu zarządzania obiektami. Wspólna zasada pozostaje jednak taka sama: użytkownik musi mieć prawo do usuwania danego widoku. Sam fakt posiadania dostępu do odczytu jego wyników nie oznacza jeszcze możliwości zmiany definicji ani skasowania obiektu.

Przed wykonaniem polecenia warto ustalić, czy widok nie jest używany przez aplikację, raport, procedurę, skrypt lub zadanie administracyjne. Baza może nie zawsze zablokować usunięcie obiektu zależnego w momencie wykonania operacji. Część zależności może być rozpoznawana przez narzędzia, a część występuje jedynie w tekstach zapytań przechowywanych poza bazą. Dlatego usunięcie widoku może ujawnić problem dopiero przy uruchomieniu określonej funkcji programu.

Składnia, zależności i bezpieczne zastosowania

Podstawowa instrukcja ma postać DROP VIEW nazwa_widoku;. Jeżeli obiekt znajduje się w konkretnym schemacie, należy uwzględnić także kwalifikator schematu, zgodnie ze składnią używaną przez dany silnik. Nie powinno się wpisywać nazwy bez sprawdzenia aktywnej bazy, schematu i środowiska. To samo polecenie wykonane w bazie testowej może być prawidłowym ćwiczeniem, a wykonane w bazie produkcyjnej może usunąć obiekt potrzebny aplikacji.

Niektóre implementacje SQL udostępniają wariant warunkowy, który nie zgłasza błędu, gdy widok już nie istnieje. Inne różnią się szczegółami składni lub obsługą obiektów zależnych. Przed użyciem takiej formy trzeba sprawdzić dokumentację wybranego produktu. W treści skryptu migracyjnego warto także jasno określić kolejność operacji: najpierw usunąć elementy, które korzystają ze starego widoku, następnie wykonać zmianę, a później utworzyć nową definicję, jeśli obiekt ma zostać zastąpiony.

Usunięcie i ponowne utworzenie widoku nie zawsze jest równoważne zmianie jego definicji. W zależności od silnika oraz sposobu wdrażania zmian operacja może wpłynąć na uprawnienia przypisane do obiektu, komentarze, metadane lub zależności rejestrowane przez narzędzia administracyjne. Z tego powodu w środowisku kontrolowanym przez migracje należy używać procedury przyjętej dla danego projektu, a nie wykonywać ręcznych zmian bez zapisu w historii wdrożeń.

Dobrym zastosowaniem DROP VIEW jest usunięcie obiektu tymczasowego po zakończeniu migracji, porządkowanie nieużywanych elementów albo zastąpienie błędnej definicji w ramach zaplanowanej zmiany. Przed operacją należy wykonać kopię tekstu definicji, ustalić właściciela obiektu, sprawdzić odwołania w kodzie i zapisać plan odtworzenia. Sama kopia danych z tabel nie wystarczy do szybkiego przywrócenia widoku, ponieważ nie zawiera jego zapytania, nazwy, schematu ani powiązanych uprawnień.

Objawy błędnego usunięcia i pytania diagnostyczne

Najczęstszym objawem jest błąd pojawiający się po uruchomieniu funkcji aplikacji, raportu albo skryptu. Komunikat może wskazywać brak widoku, nieznaną nazwę obiektu lub nieistniejący element schematu. Taki błąd nie dowodzi jeszcze, że zniknęły rekordy. W pierwszej kolejności należy rozdzielić problem z definicją obiektu od problemu z połączeniem do niewłaściwej bazy, niewłaściwym schematem albo kontem pozbawionym odpowiednich praw.

Jeżeli widok został usunięty przypadkowo, można go odtworzyć tylko wtedy, gdy zachowała się jego definicja. Należy sprawdzić pliki migracji, kopie konfiguracji, repozytorium kodu, dokumentację wdrożeniową oraz skrypty tworzące strukturę bazy. Odtworzenie samej nazwy nie wystarczy, jeżeli aplikacja oczekuje określonych kolumn, typów danych, filtrów lub aliasów. Nowa definicja musi odpowiadać kontraktowi używanemu przez kod.

Warto również sprawdzić, czy usuwany widok nie był wykorzystywany pośrednio. Odwołanie może znajdować się w innym widoku, procedurze, funkcji, raporcie, pliku zapytania lub konfiguracji aplikacji. Wyszukanie identycznego tekstu nie zawsze wystarcza, ponieważ nazwa może być składana dynamicznie albo przekazywana jako parametr. Przydatne jest porównanie listy obiektów przed i po zmianie, analiza logów aplikacji oraz odtworzenie operacji na kopii środowiska.

Osobne pytanie dotyczy transakcji. Zachowanie DROP VIEW przy błędzie, wycofaniu transakcji lub częściowym wykonaniu skryptu zależy od użytego silnika i kontekstu. Nie należy zakładać, że każda seria poleceń DDL cofnie się w identyczny sposób. Plan zmiany powinien uwzględniać dokumentację konkretnego produktu, sposób wykonywania migracji oraz możliwość przywrócenia poprzedniej definicji.

Rzadko spotykany, starszy widok może nadal być potrzebny jednemu narzędziu lub archiwalnemu modułowi. Przed porządkowaniem bazy dobrze jest sprawdzić historię użycia, harmonogramy zadań i okresowe raporty, ponieważ brak aktywności w krótkim wycinku logów nie oznacza, że obiekt jest zbędny. Usuwanie starych obiektów wymaga więc potwierdzenia, a nie wyłącznie oceny nazwy lub daty utworzenia.

Gdzie kończy się sam skrypt, a zaczyna diagnostyka komputera

Jeżeli polecenie zostało wykonane na laptopie albo komputerze stacjonarnym, a po nim aplikacja przestała działać, przyczyna może leżeć zarówno w bazie, jak i w lokalnym środowisku pracy. Trzeba ustalić, czy program łączy się z właściwym źródłem danych, czy pliki konfiguracyjne nie zostały zmienione, czy użytkownik ma dostęp do wymaganej lokalizacji oraz czy system nie zgłasza problemów z dyskiem, pamięcią lub zasilaniem. Bez tego łatwo pomylić błąd logiczny w bazie z awarią komputera.

Warszawskie Pogotowie Komputerowe prowadzi naprawę sprzętową laptopów i komputerów stacjonarnych wraz z podzespołami.

Do serwisu warto zgłosić komputer, gdy problemy z dostępem do aplikacji współwystępują z samoczynnymi wyłączeniami, zawieszaniem systemu, błędami odczytu dysku, uszkodzeniem plików, brakiem obrazu albo niestabilnym działaniem pamięci. W takiej sytuacji najpierw należy zabezpieczyć ważne dane i unikać wielokrotnego uruchamiania programów zapisujących na uszkodzonym nośniku. Diagnoza sprzętu może wyjaśnić, dlaczego skrypt nie wykonuje się poprawnie, ale sama naprawa komputera nie odtworzy usuniętej definicji widoku.

Jeśli problem dotyczy wyłącznie struktury bazy, potrzebne będą informacje o używanym silniku SQL, nazwie bazy, schemacie, dokładnym komunikacie błędu, czasie wykonania operacji i dostępnych kopiach definicji. Jeżeli natomiast komputer wykazuje objawy awarii, należy przekazać także opis zachowania urządzenia oraz informację, czy dane są jedyną dostępną kopią. Rozdzielenie tych dwóch obszarów przyspiesza ustalenie, czy należy odtworzyć obiekt w bazie, naprawić środowisko pracy, czy najpierw zabezpieczyć nośnik.