7 faktów na temat synonimów SQL Server, które powinieneś wiedzieć

Zanim pojawiły się synonimy SQL Server, wszyscy chcieli uprościć i ulepszyć korzystanie z bazy danych.

Wyobraź sobie, że masz aplikację z bazą danych, która odwołuje się do innej bazy danych z tego samego serwera. Następnie poważna reorganizacja zmusza Twój zespół do przeniesienia drugiej bazy danych na inny serwer.

Nie ma wątpliwości, że Twoja aplikacja się zepsuje. Ale co zrobisz w takim przypadku? Połączyć 2 serwery i zakodować wszystkie odniesienia (ponownie), aby wskazać nowy serwer?

Możesz to zrobić, jeśli chcesz i zapomnieć, jeśli masz tylko kilka lub kilkanaście odniesień do tego. Ale jeśli nastąpi kolejny transfer lub zmiana nazwy, będziesz musiał powtórzyć ten sam koszmar.

Niemniej jednak istnieje lepszy sposób radzenia sobie z tym.

Przedstawiamy synonimy SQL Server

Zanim zagłębimy się w to, co możesz zrobić z synonimami SQL Server, opiszmy, czym one są.

Synonim w dowolnym języku mówionym i pisanym odnosi się do słowa lub frazy, która ma takie samo znaczenie jak inne słowo lub fraza. Tak więc słowo wspaniały jest synonimem pięknego i atrakcyjny .

Podobnie do tego, co wiemy o synonimach słów i fraz, synonimy SQL Server odnoszą się do alternatywnej nazwy obiektu bazy danych znajdującego się na lokalnym lub zdalnym serwerze. Przeczytaj więcej tutaj.

Jak zobaczysz w poniższych faktach, synonimy SQL Server mogą znacznie ułatwić konserwację Twojej aplikacji.

Zacznijmy więc!

1. Synonimy SQL Server mogą uprościć Twoją pracę, gdy obiekty podstawowe są przenoszone lub zmieniane

Po pierwsze, oszczędzą ci kłopotów ze zmianami kodu, gdy baza danych zostanie przeniesiona na inny serwer lub zmieniona z jakiegokolwiek powodu. Odnieśmy się do scenariusza, o którym wspomnieliśmy w tym wpisie otwierającym.

Poważna reorganizacja zmusza Twój zespół do zmiany odniesienia do wszystkich obiektów w mydatabase2 do prodserver2.mydatabase2.

Więc pytasz sys.sql_modules ze wszystkimi wystąpieniami mydatabase2 z mojej bazy danych1 .

USE mydatabase1
GO
SELECT
 b.name
,a.definition
,b.type_desc
FROM sys.sql_modules a
INNER JOIN sys.all_objects b on a.object_id = b.object_id
WHERE a.definition like '%mydatabase2%'
GO

Teraz wynik powyższego skryptu wyświetli listę wszystkich obiektów mających odniesienia do mydatabase2 . Nieźle, co? Pomoże to określić zakres prac, które należy wykonać.

Ale to dopiero początek. Musisz również sprawdzić, czy w Twojej aplikacji klienckiej znajduje się kod lub jakikolwiek inny kod, który odwołuje się do tego samego poza Twoją bazą danych.

Ilość kodu, którego to dotyczy, pokazuje, jak duży jest Twój nowy problem.

Oto kilka ciekawostek dotyczących tego, co dzieje się w tym skrypcie:

sys.sql_modules zawierać obiekty SQL, które są modułami zdefiniowanymi przez SQL, takimi jak widoki, procedury składowane, funkcje itp.
Nazwa kolumna jest tam, gdzie znajduje się nazwa obiektu.
Kod SQL obiektu znajduje się w definicji kolumna sys.sql_modules .
sys.all_objects uwzględnij wszystkie obiekty w swojej bazie danych, takie jak tabele, widoki itp.
Wzięliśmy type_desc kolumna, aby określić typ obiektu (widok, procedura składowana itp.)
Gdzie klauzula filtruje zapytanie pod kątem dowolnego kodu SQL zawierającego odwołanie do mydatabase2 .
Aby uzyskać satysfakcjonujący wynik przy użyciu powyższego skryptu, musisz mieć uprawnienia do wszystkich obiektów. Skontaktuj się z administratorem bazy danych lub osobą o podobnej roli. Możesz to również sprawdzić.

Teraz, gdy wiesz, jak uzyskać zakres swojej pracy, nadszedł czas, aby to naprawić.

Jak naprawić ten bałagan w kodzie, aby się więcej nie powtórzył

W porządku. Muszę się przyznać.

Używanie synonimów SQL Server tylko ograniczy Twoje problemy do minimum, ale ich nie wyeliminuje.

Teraz, gdy to już na uboczu, mamy dobrą wiadomość:jeśli masz 10 odniesień do zdalnego obiektu przed użyciem synonimów, modyfikujesz wszystkie 10. Ale kiedy zaczniesz używać synonimu dla tego zdalnego obiektu, zamiast modyfikować 10 wystąpień, zmieniasz tylko 1. Nic więcej.

Oto kroki, aby to naprawić za pomocą synonimów:

Utwórz synonim dla każdego zdalnego obiektu. Więc zamiast prodserver2.mydatabase2.schema1.object1 możesz odnieść się do niego za pomocą synonimu.
Zmień odniesienia do każdego obiektu na jego synonim.

Później dowiesz się, jak to zrobić.

Na wynos:

Synonimy zapewniają warstwę abstrakcji, aby chronić odwołania do obiektów bazowych z dowolnej części kodu, zarówno w bazie danych, aplikacji klienckiej, jak i gdziekolwiek indziej. Możesz więc cieszyć się, gdy nastąpi kolejna zmiana, niezależnie od tego, czy jest to przeniesienie obiektu, czy zmiana nazwy.

2. Możesz tworzyć synonimy SQL Server dla większości obiektów

Następnie zastanówmy się, jakie obiekty mogą mieć synonimy?

Stoły
Widoki
Procedury przechowywane
Funkcje

Teraz, gdy znasz typy obiektów, możesz mieć pojęcie, co możesz zrobić z synonimami. Bądźmy bardziej konkretni.

3. Możesz wydawać odpowiednie polecenia dla synonimu obiektu

Po trzecie, oto kilka konkretnych poleceń dla każdego typu obiektu.

Stoły

O ile możesz wykonać SELECT, INSERT, UPDATE i DELETE w tabeli, możesz zrobić to samo z jej synonimem.

Więc zamiast:

SELECT * FROM prodserver2.mydatabase2.schema1.table1

Możesz mieć krótszą wersję, która będzie odporna na następną zmianę:

SELECT * FROM synonym1

Ponieważ tak jest, możesz również zrobić to:

UPDATE synonym1
SET column1 = <value>

To samo dotyczy INSERT i DELETE.

Należy jednak pamiętać o następujących kwestiach:

Wstawienie nowego rekordu przez synonim spowoduje dodanie nowego rekordu do tabeli podstawowej. W naszym przypadku prodserver2.mydatabase2.schema1.table1 .
Aktualizacja i usunięcie będą miały ten sam efekt.

Do tej pory pokazaliśmy tylko polecenia DML. Co powiesz na polecenia DDL, takie jak DROP?

Niestety nie możesz ich wykonać. Oto powód, dla którego:

Usunięcie synonimu nie spowoduje usunięcia tabeli podstawowej. Porzuci synonim. Za chwilę omówię to szczegółowo.

Ale jest jeszcze jedna rzecz, którą możesz zrobić z synonimami tabel SQL Server:JOIN.

Jak wygodne może to być? Zamiast tego:

SELECT
 a.column1
,b.column1
FROM table3 a
INNER JOIN prodserver2.mydatabase2.schema1.table1 b on a.id = b.id

Możesz to zrobić:

SELECT
 a.column1
,b.column1
FROM table3 a
INNER JOIN synonym1 b on a.id = b.id

Czy to jest prostsze? Jasne!

Przechowywane procedury

Jednym z odpowiednich poleceń, które możesz wykonać z synonimem procedury składowanej, jest EXEC.

Więc zamiast wywoływać zdalną procedurę, taką jak ta:

EXEC prodserver2.mydatabase2.schema1.spProcedure1

Możesz utworzyć synonim dla powyższej procedury. Nazwijmy to synProcedure1 . I wywołaj to w ten sposób:

EXEC synProcedure1

Powinniśmy kontynuować? To samo możesz zrobić z WIDOKAMI i FUNKCJAMI. Oczywiście, jeśli masz wymagane uprawnienia. Ale najpierw omówmy, jak utworzyć synonimy SQL Server.

4. Możesz rozpocząć swoją przygodę z synonimami SQL Server dzięki CREATE

Dotarliśmy do punktu, w którym możesz tworzyć synonimy. Oto jak możemy to zrobić za pomocą T-SQL dla tabeli:

CREATE SYNONYM synonym1 FOR prodserver2.mydatabase2.schema1.table1

Ale zwróć uwagę na to zastrzeżenie:

Sprawdzanie istnienia i pozwolenia na mydatabase2.schema1.table1 w prodserver2 jest odroczone do czasu działania.

Oznacza to, że nie będziesz wiedzieć, czy:

2 serwery (prodserver1 i prodserver2 ) są już połączone.
baza danych mydatabase2 , schemat schema1 , a tabela tabela1 faktycznie istnieje.
Twój dostęp do tych zasobów jest dozwolony.

Tak więc po utworzeniu synonimu przetestuj go, uruchamiając polecenia, które mają działać.

A z procedurami składowanymi, widokami i funkcjami powinieneś zachowywać się w ten sam sposób.

Ale to nie wszystko. Jeśli możemy stworzyć synonim, możemy go również usunąć za pomocą:

DROP SYNONYM synonym1

A oto kolejne zastrzeżenie:ponieważ możesz usunąć synonimy w dowolnym momencie, odniesienia do usuniętych synonimów będą sprawdzane tylko w czasie wykonywania.

Więc przed upuszczeniem synonimu, sprawdź sys.sql_modules jeśli są jakieś odniesienia do tego.

Korzystanie z SQL Server Management Studio (SSMS) do tworzenia i usuwania synonimów

Do tej pory używaliśmy T-SQL do tworzenia i usuwania synonimów SQL Server. Możesz chcieć użyć interfejsu graficznego, robiąc to samo.

Rozkręćmy piłkę.

Tworzenie synonimów

Jeśli wpisywanie poleceń nie jest Twoją rzeczą, oto kroki, które należy wykonać, jeśli chodzi o tworzenie synonimów:

Uruchom SSMS i zaloguj się do swojego serwera SQL.
Poszukaj bazy danych, w której chcesz utworzyć synonim.
Rozwiń.
Kliknij prawym przyciskiem myszy Synonimy folderu i wybierz Nowy synonim .
Wypełnij formularz informacjami wymaganymi dla synonimów, w tym nazwą, schematem itp.
Kliknij OK .

Poniżej znajduje się zrzut ekranu formularza w SSMS:

Upuszczanie synonimów

Mówiąc o preferencjach, wpisywanie poleceń do tworzenia synonimów to moja rzecz. Ale upuszczanie ich do woli jest prostsze niż wpisywanie poleceń. Oczywiście to tylko mój gust. W każdym razie poniżej znajdują się kroki, które należy wykonać, gdy upuszczasz synonim:

Uruchom SSMS i zaloguj się do swojego serwera SQL.
Poszukaj bazy danych, w której znajduje się synonim, który chcesz usunąć.
Rozwiń.
Rozwiń synonimy folder.
Poszukaj synonimu, który chcesz usunąć.
Kliknij prawym przyciskiem myszy synonim, który chcesz usunąć, i wybierz Usuń .
Kliknij OK .

Aby podsumować powyższe kroki, po prostu kliknij prawym przyciskiem myszy synonim do usunięcia, a następnie wybierz Usuń i na koniec kliknij OK .

Poniżej znajduje się zrzut ekranu okna, które pojawi się przed potwierdzeniem usunięcia:

5. Możesz zabezpieczyć synonimy SQL Server

Używając GRANT, DENY lub REVOKE, możesz kontrolować dostęp do synonimu.

Aby PRZYZNAĆ uprawnienie SELECT do synonimu synonim1 do użytkownika o nazwie testuser , wykonaj następujące czynności:

GRANT SELECT ON synonym1 to testuser

Inne uprawnienia, które możesz dodać do synonimu lub usunąć z niego, to:

KONTROLA
WYKONAJ
AKTUALIZUJ
WSTAW
USUŃ
WIDOK DEFINICJI
PRZEJMIJ WŁASNOŚĆ

6. Nie możesz znaleźć tej tabeli, widoku lub procedury? To może być synonim

Jednym z problemów, jakie może napotkać nowicjusz w Twoim zespole, jest „brakująca” tabela, widok, procedura lub funkcja. Oczywiście, jeśli SELECT zostanie wystawiony na obiekt, może to być tabela lub widok. Ale nie może go znaleźć na liście tabel lub liście widoków. A jeśli wcześniej nie używał synonimów SQL Server, to dodatkowy problem.

Brak orientacji, luka w dokumentacji lub luka w Twoich standardach można uporządkować. Oto sprytny skrypt, który pomoże Ci zaprezentować listę synonimów i ich obiekt podstawowy nowemu członkowi zespołu:

SELECT
 a.[name]
,a.[base_object_name]
,OBJECTPROPERTYEX(OBJECT_ID(a.[name]), 'BaseType') as BaseType
,b.type_desc
FROM sys.synonyms a
INNER JOIN (SELECT DISTINCT type, type_desc from sys.all_objects) b on 
           CONVERT(varchar(2),OBJECTPROPERTYEX(OBJECT_ID(a.[name]), 'BaseType')) = b.type

„Brakujący” przedmiot? Już nie, jeśli to synonim.

Ale zanim zaczniesz ekscytować się uruchamianiem tego skryptu, oto kilka rzeczy, które powinieneś wziąć pod uwagę:

sys.synonimy to miejsce, w którym wszystkie synonimy SQL Server są zdefiniowane w bieżącej bazie danych.
Wzięliśmy typy i opisy typów (typ i type_desc odpowiednio) w sys.all_objects . Jeśli masz lepszy pomysł niż dołączenie do nich za pomocą podzapytania, daj mi znać.
OBJECTPROPERTYEX służy do uzyskania typu obiektu bazowego, jeśli jest to tabela, procedura składowana lub w inny sposób.
Na koniec, jeśli nie masz minimalnych uprawnień wymaganych do wykonania tego skryptu i uzyskania pożądanych wyników, czas zaprzyjaźnić się z DBA lub kimś o podobnej roli:)

Ale możesz się zastanawiać, po co to wszystko robić, jeśli nie będzie dobrze działać?

7. Czy synonimy SQL Server wpłyną na wydajność?

To powszechny problem. Aby wyjaśnić, co dzieje się za kulisami, spójrzmy na podsumowanie tego, co wydarzy się w planie wykonania:

Podczas wykonywania najprostszego kodu z synonimem (np. SELECT * from synonym1), SQL Server wejdzie w fazę wiązania, w której obiekt bazowy zastąpi synonim.
Następnie, niezależnie od tego, jaki jest najlepszy plan optymalizacji wykonywania polecenia dla obiektu bazowego, będzie on taki sam.

Oto kilka pytań i odpowiedzi dotyczących dwóch powyższych stwierdzeń:

Jak długo SQL Server wykonuje fazę wiązania? ODPOWIEDŹ:To nie trwa długo. Zwykle dzieje się to w mgnieniu oka.
Jeśli w następnym kroku wykorzystany zostanie ten sam najlepszy plan optymalizacji z obiektem bazowym, a zapytanie do obiektu bazowego będzie „wystarczająco szybkie”, czy będzie wolniejsze? ODPOWIEDŹ:Nie, ponieważ użyje tego samego planu wykonania.
Co powiesz na uwierzytelnianie z nowego serwera? ODPOWIEDŹ:Jeśli występują niewielkie opóźnienia spowodowane przeniesieniem bazy danych na nowy serwer, to nie są one spowodowane synonimem. Zapytanie o wydajność wywoływania go za pomocą synonimu lub zakodowania server.database.schema.object powinien być taki sam, ponieważ synonim jest tylko alternatywną nazwą obiektu bazowego. Rozwiąż problem z niską wydajnością obiektu bazowego.

Ale nie wierz mi na słowo. Powinieneś to sprawdzić samodzielnie z planem wykonania zapytania i rzeczywistą wydajnością.

Wniosek

Podsumowując, omówiliśmy prawie wszystko na temat synonimów SQL Server, więc podsumujmy.

Po pierwsze, synonim to po prostu alternatywna nazwa, która uchroni Cię przed zmianami i przenoszeniem nazw obiektów. Po drugie, dobrymi kandydatami na synonimy są tabele, widoki, procedury składowane i funkcje. Następnie możesz wykonać polecenia odpowiednie dla jego obiektu bazowego z synonimu. Ty też możesz to zabezpieczyć. Następnie, jeśli chcesz zobaczyć listę synonimów, masz sys.synonimy pomóc Ci. Wreszcie, wydajność nie powinna stanowić większego problemu, jeśli nie ma problemów z wydajnością obiektu bazowego.

Dlaczego więc nie wypróbować tego dzisiaj?

Co myślisz? Daj nam znać w komentarzach.