Od czasu do czasu może zajść potrzeba zmiany nazwy obiektu bazy danych z różnych powodów. W takiej sytuacji bardzo przydatne mogą okazać się natywne funkcje zmiany nazw obiektów bazy danych SQL Server. Istnieją jednak duże różnice pomiędzy zwykłą zmianą nazwy obiektów bazy danych SQL Server w SQL Server Management Studio, a bezpieczną zmianą nazwy za pomocą ApexSQL Refactor.
W tym artykule zostaną wyjaśnione różnice pomiędzy zmianą nazwy obiektów bazy danych za pomocą SSMS, a funkcją bezpiecznej zmiany nazwy w ApexSQL Refactor.
W poniższym przykładzie utwórzmy nową bazę danych NewDB oraz dwie tabele Użytkownicy i Adres. Tabela Adres będzie posiadała referencje obce do tabeli Użytkownicy:
CREATE DATABASE NewDB;CREATE TABLE Users (UserID INT PRIMARY KEY IDENTITY(1, 1),FirstName VARCHAR(20),Lastname VARCHAR(50),Address VARCHAR(250))GOCREATE TABLE Address (ID INT NOT NULL IDENTITY(1, 1),City VARCHAR(120),PostalCode INT,UserAddressID INT FOREIGN KEY REFERENCES Users(UserID))GO
Następnie utwórzmy dwie procedury składowane sp_GetUserAddress oraz sp_GetUserCity:
CREATE PROCEDURE sp_GetUserAddressASBEGINSELECT FirstName,Lastname,AddressFROM UsersENDGOCREATE PROCEDURE sp_GetUserCityASBEGINSELECT Users.FirstName,Users.Lastname,Address.CityFROM UsersINNER JOIN Address ON Users.UserID = Address.UserAddressIDENDGO
A na koniec utwórz widok v_Address01 i wyzwalacz trgAfterInsert:
CREATE VIEW .ASSELECT ID,City,PostalCode,UserAddressIDFROM dbo.AddressINNER JOIN Users ON Users.UserID = Address.UserAddressIDGOCREATE TRIGGER trgAfterInsert ON .FOR INSERTASPRINT 'Data entered successfully'GO
Zmienianie nazw obiektów bazy danych za pomocą SSMS
Aby zobaczyć zależności dla tabeli Użytkownicy, należy zaznaczyć ją w Object Explorerze i wybrać z menu kontekstowego polecenie View Dependencies.
Polecenie to otworzy okno Zależności obiektów dla wybranej tabeli, w tym przypadku dla tabeli Użytkownicy. Na liście w oknie Zależności obiektów znajdują się wszystkie obiekty z bazy danych NewDB, które zależą od tabeli Użytkownicy:
Część z nich posiada zależności schematycznie związane z tabelą Użytkownicy (triger trgAfterInsert oraz tabela Adres), a część posiada zależności nieschematyczne (procedury składowane sp_GetUserCity i sp_GetUserAddress oraz widok v_Adres01).
Obiekty bazy danych, które posiadają zależności od tabeli Użytkownicy, automatycznie zaakceptują wszystkie wprowadzone zmiany. Po zmianie nazwy tabeli Użytkownicy nie wystąpią żadne błędy związane z zależnościami.
Jednakże zmiana nazwy tabeli Użytkownicy spowoduje unieważnienie obiektów niezwiązanych ze schematem. Aby móc korzystać z tych obiektów bazy danych po zmianie nazwy tabeli Users, należy ręcznie zmodyfikować ich kod.
Aby zobaczyć to na przykładzie, zaznaczamy tabelę Users w oknie Object Explorer i z menu kontekstowego klikamy polecenie Rename:
Podajemy nową nazwę dla tabeli Users, np. NewUsers i odświeżamy bazę danych NewDB. Na liście tabel zostanie zmieniona jej nazwa na NewUsers:
Po wpisaniu nowej nazwy tabeli i odświeżeniu bazy danych zmieni się lista obiektów, do których się odwołujemy. Sprawdź czy zmieniły się zależności dla zmienionej nazwy tabeli NewUsers. Ponownie zaznacz tabelę NewUsers i kliknij polecenie Wyświetl zależności:
Lista obiektów odwołujących się jest teraz zmieniona.
Procedura składowana sp_GetUserAddress nie znajduje się już na liście obiektów odwołujących się. Wykonanie tej procedury zakończy się następującym komunikatem:
Msg 208, Level 16, State 1, Procedure sp_GetUserAddress, Line 4
Nieprawidłowa nazwa obiektu 'Users'.
Z drugiej strony, procedura składowana sp_GetUserCity oraz widok v_Address01 nadal znajdują się na liście, ale gdy zostaną użyte, zostaną podniesione błędy:
Msg 208, Level 16, State 1, Procedure sp_GetUserCity, Line 8
Invalid object name 'dbo.Users'.
Msg 208, Level 16, State 1, Procedure v_Address01, Line 8
Nieprawidłowa nazwa obiektu 'dbo.Users'.
Msg 4413, Level 16, State 1, Line 1
Could not use view or function 'v_Address01′ because of binding errors.
To dowód na to, że zmiana nazwy tabeli za pomocą SSMS nie spowoduje automatycznej aktualizacji wszystkich obiektów bazy danych, które się do niej odwołują. Kod obiektów, które mają nieschematycznie powiązane zależności z tabelą Users, musi zostać ręcznie zaktualizowany. Dopóki nie zostanie otwarty skrypt każdego obiektu i każde odwołanie do tabeli Users nie zostanie zmienione na NewUsers, nie będzie można dalej bezbłędnie korzystać z tych obiektów.
Zmienianie nazw obiektów bazy danych za pomocą ApexSQL Refactor
ApexSQL Refactor, dodatek do Visual Studio oraz SSMS, udostępnia ponad 200 opcji formatowania oraz 15 refaktorów kodu do formatowania i refaktoryzacji kodu SQL oraz obiektów bazy danych.
Jedną z funkcji refaktoryzacji kodu SQL w ApexSQL Refactor jest Bezpieczna zmiana nazwy. Funkcja ta umożliwia zmianę nazwy obiektów serwera SQL bez naruszania zależności od bazy danych. Obiektami bazy danych, których nazwy mogą być zmieniane za pomocą tej funkcji są: tabele, widoki, procedury, funkcje, kolumny tabel/widoków oraz parametry procedur/funkcji.
Aby zobaczyć, jak działa funkcja bezpiecznej zmiany nazwy, wybierz tabelę Użytkownicy w Eksploratorze obiektów i z menu kontekstowego kliknij polecenie Bezpieczna zmiana nazwy:
Albo wybierz tę samą opcję z menu głównego ApexSQL Refactor:
Pojawi się okno Bezpieczna zmiana nazwy:
W polach Nowy schemat oraz Nowa nazwa podajemy schemat oraz nazwę wybranej tabeli.
Powiadomienie – żółty migający trójkąt – informuje, że tabela o tym schemacie i nazwie już istnieje.
W tym oknie można zmienić schemat tabeli wybierając jeden z istniejących schematów bazy danych z listy rozwijanej. Podczas zmiany nazwy tabeli za pomocą SSMS nie jest to jedna z opcji. Z tego powodu dla tego przykładu schemat tabeli nie zostanie zmieniony.
Wstaw nową nazwę tabeli w polu Nowa nazwa. Ważną rzeczą, którą należy wiedzieć jest to, że nie ma żadnych ograniczeń dla używanych znaków. Dla tego przykładu nowa nazwa tabeli Users będzie brzmiała NewUsers.
Kliknij przycisk Preview, znajdujący się w lewym dolnym rogu okna Safe rename.
W zakładce Generated script znajduje się skrypt refaktoryzacji T-SQL, który po wykonaniu zmieni nazwę tabeli Users. W tym oknie nie można zmienić skryptu, można go jedynie przejrzeć:
W zakładce Warnings znajdą się wszystkie ostrzeżenia związane ze zmianą nazwy tabeli. Dla tego przykładu, nie ma żadnych ostrzeżeń:
Aby sprawdzić wszystkie akcje, które zostaną wykonane przy zmianie nazwy tabeli Użytkownicy, należy kliknąć na zakładkę Kolejność. Wszystkie akcje są uporządkowane w ten sposób, aby ich wykonanie zapobiegło zerwaniu zależności pomiędzy obiektami:
W zakładce Zależności znajduje się lista wszystkich obiektów bazy danych, do których odwołuje się tabela Użytkownicy. ApexSQL Refactor nie robi różnicy pomiędzy obiektami zależnymi związanymi i niezwiązanymi ze schematem, ponieważ wszystkie obiekty zostaną zaktualizowane niezależnie od typu zależności do tabeli Użytkownicy:
W celu zmiany nazwy tabeli Użytkownicy wystarczy kliknąć przycisk Utwórz skrypt. Wygenerowany skrypt zostanie otwarty w oknie edytora zapytań SSMS:
W edytorze zapytań można modyfikować skrypt lub wykonać go w stanie niezmienionym. Po wykonaniu pojawi się następujący komunikat:
Uwaga: Zmiana jakiejkolwiek części nazwy obiektu może spowodować uszkodzenie skryptów i procedur składowanych.
Po odświeżeniu bazy NewDB na liście tabel, zamiast tabeli Users pojawi się tabela NewUsers, tak samo jak po zmianie nazwy tabeli za pomocą SSMS, ale z jedną istotną różnicą – żaden z obiektów do których się odwołujemy nie jest niepoprawny.
Tylko dla sprawdzenia, jeżeli sprawdzimy zależności dla zmienionej nazwy tabeli NewUsers za pomocą funkcji SSMS View dependencies, pojawi się następująca lista:
Ta lista jest dokładnie taka sama jak pierwsza, przed zmianą nazwy tabeli za pomocą ApexSQL Refactor.
Dzięki funkcji bezpiecznej zmiany nazwy w ApexSQL Refactor zmiana nazwy tabeli jest łatwiejsza, a co więcej nie wymaga dodatkowej pracy przy zmianie wszystkich obiektów, do których się odwołujemy. Ponadto w jednym oknie można sprawdzić wszystkie kwestie związane ze zmianą nazwy (ostrzeżenia, sekwencje, zależności).
Prezentowany przykład pokazuje, jak zmienić nazwę tabeli, ale te same kroki można wykonać w przypadku zmiany nazwy dowolnego obiektu bazy danych SQL Server (kolumny tabeli/widoku, parametry funkcji/procedur, widoki, funkcje, procedury).
W tym przykładzie pokazano, jak zmienić nazwę tabeli.