WITH SCHEMABINDING wiąże widok z definicją tabel źródłowych, uniemożliwiając ich zmianę bez usunięcia powiązania.
Jak działa WITH SCHEMABINDING w widoku SQL Server
WITH SCHEMABINDING jest opcją definicji widoku w Microsoft SQL Server. Powoduje powiązanie metadanych widoku z obiektami, których używa jego zapytanie, najczęściej z tabelami lub innymi widokami znajdującymi się w tej samej bazie danych. SQL Server sprawdza wtedy, czy zmiany schematu obiektów źródłowych nie naruszą definicji widoku. Jeżeli zmiana mogłaby spowodować, że zapytanie widoku przestanie być poprawne, operacja jest blokowana do czasu usunięcia albo zmodyfikowania zależności.
Przykładowa definicja może wyglądać następująco: CREATE VIEW dbo.v_Sprzedaz AS SELECT Id, DataSprzedazy, Kwota FROM dbo.Sprzedaz WITH SCHEMABINDING;. Nazwa tabeli została podana wraz ze schematem, czyli jako nazwa dwuczłonowa. Przy schemabindingu SQL Server wymaga jawnego wskazania takich nazw dla obiektów używanych przez widok. Nie można w tym przypadku polegać na niekwalifikowanej nazwie tabeli ani odwoływać się do obiektu z innej bazy danych.
Ograniczenia definicji chroniące zależności
Widok ze schemabindingiem powinien wymieniać konkretne kolumny zamiast używać SELECT *. Dzięki temu struktura wyniku pozostaje jednoznaczna, a dodanie nowej kolumny do tabeli źródłowej nie zmienia po cichu interfejsu widoku. W definicji trzeba również stosować nazwy obiektów poprzedzone schematem, na przykład dbo.Klienci i dbo.Zamowienia. Wszystkie obiekty referencjonowane przez widok muszą znajdować się w tej samej bazie danych.
Schemat wiąże się z określonymi ograniczeniami języka zapytań. W zależności od konstrukcji widoku niedozwolone mogą być między innymi odwołania do tabel tymczasowych, zmiennych tabelarycznych, obiektów zewnętrznych oraz elementów, których definicja nie zapewnia stabilnej zależności. SQL Server odrzuca definicję, jeżeli nie może zagwarantować poprawnego powiązania. Samo dodanie klauzuli do dowolnego istniejącego zapytania nie zawsze wystarczy, ponieważ zapytanie może wymagać uporządkowania nazw, listy kolumn albo użytych funkcji.
Ochrona dotyczy przede wszystkim zmian strukturalnych. Można nadal wykonywać operacje INSERT, UPDATE i DELETE na tabelach źródłowych, o ile pozwalają na to uprawnienia i ograniczenia tabel. Schematbinding nie jest więc blokadą zapisu danych ani mechanizmem kontroli poprawności wartości. Nie tworzy także kopii danych. Widok nadal wykonuje swoje zapytanie względem aktualnego stanu obiektów źródłowych, chyba że zostanie dodatkowo zmaterializowany w ramach mechanizmu indeksowanego widoku.
Zmiana tabeli, modyfikacja widoku i indeksowany widok
Jeżeli kolumna używana przez widok jest związana schematem, próba jej usunięcia, zmiany typu lub innej modyfikacji wpływającej na definicję może zakończyć się błędem. Najpierw trzeba zmienić albo usunąć widok, a następnie wykonać zmianę w tabeli. W praktyce bezpieczny proces obejmuje odczyt zależności, przygotowanie nowej definicji widoku, wykonanie kontrolowanej migracji i ponowne sprawdzenie zapytań korzystających z jego nazw oraz typów kolumn.
Istniejący widok można zmienić poleceniem ALTER VIEW, zachowując wymagania schemabindingu. Nie należy jednak traktować tego jako automatycznej aktualizacji wszystkich obiektów zależnych. Zmiana listy kolumn lub typów danych może wymagać przejrzenia zapytań, procedur i aplikacji, które odwołują się do widoku. Warto także pamiętać, że widok nie gwarantuje kolejności wierszy bez odpowiedniego ORDER BY użytego w dozwolonym kontekście zapytania zewnętrznego; schemabinding dotyczy zależności schematu, a nie sortowania wyniku.
WITH SCHEMABINDING jest również wymaganym elementem przy tworzeniu indeksowanego widoku w SQL Server, ale sama klauzula nie tworzy indeksu i nie powoduje automatycznego przechowywania wyniku. Indeksowany widok podlega dodatkowym regułom dotyczącym konstrukcji zapytania, deterministyczności wyrażeń, ustawień sesji, ograniczeń tabel oraz kolejności tworzenia indeksów. Typowy proces zaczyna się od utworzenia widoku z odpowiednią definicją, a następnie obejmuje utworzenie wymaganego unikatowego indeksu klastrowanego. Dopiero wtedy SQL Server może utrzymywać fizyczną reprezentację wyniku.
Kontrola definicji podczas diagnostyki komputera
W środowisku z SQL Server błędy związane z WITH SCHEMABINDING zwykle wymagają sprawdzenia dokładnego komunikatu silnika, definicji widoku oraz planowanej zmiany tabeli. Należy zweryfikować, czy wszystkie nazwy mają postać dwuczłonową, czy lista kolumn jest jawna oraz czy zapytanie nie korzysta z obiektu spoza bieżącej bazy. Przydatne jest porównanie skryptu wdrożeniowego z aktualnym stanem obiektów, ponieważ problem może wynikać z kolejności migracji, różnicy schematów albo próby zmiany kolumny używanej przez zależny widok.
Warszawskie Pogotowie Komputerowe zajmuje się profesjonalną naprawą laptopów, komputerów PC i ich podzespołów. W przypadku problemu z aplikacją bazodanową na komputerze można rozpocząć od ustalenia, czy błąd wynika z samego silnika SQL Server, niezgodnej definicji widoku, uprawnień, konfiguracji programu czy awarii systemu operacyjnego. Takie rozróżnienie pozwala nie usuwać pochopnie widoku ani tabeli i ograniczyć działania do elementu, który rzeczywiście powoduje problem.
