7 факта за синонимите на SQL Server, които трябва да знаете

Преди да се появят синонимите на SQL Server, всеки иска да опрости и подобри работата си с базата данни.

Представете си, че имате приложение с база данни, която препраща към друга база данни от същия сървър. След това голяма реорганизация принуждава екипа ви да прехвърли другата база данни на друг сървър.

Няма съмнение, че приложението ви ще се счупи. Но какво ще направите в такъв случай? Свържете 2-та сървъра и твърдо кодирайте всички препратки (отново), за да сочат към новия сървър?

Можете да направите това, ако искате и да забравите, ако имате само няколко или дузина препратки към него. Но ако се случи друго прехвърляне или преименуване, ще трябва да повторите същия кошмар.

Въпреки това има по-добър начин да се справите с това.

Представяме синоними на SQL Server

Преди да се потопим в това какво можете да правите със синонимите на SQL Server, нека опишем какви са те.

Синоним във всеки говорим и писмен език се отнася до дума или фраза, която има същото значение като друга дума или фраза. И така, думата разкошен е синоним на красив и привлекателен .

Подобно на това, което знаем за синонимите на думи и фрази, синонимите на SQL Server се отнасят до алтернативно име на обект на база данни, намиращ се в локален или отдалечен сървър. Прочетете повече тук.

Както ще видите от следните факти, синонимите на SQL Server могат да направят поддръжката на вашето приложение много по-лесна.

И така, нека да започнем!

1. Синонимите на SQL Server могат да опростят работата ви, когато базовите обекти се прехвърлят или преименуват

Първо, те ще ви спестят от проблемите с промените в кода, когато база данни бъде преместена на друг сървър или преименувана по някаква причина. Нека се обърнем към сценария, който споменахме в началото на тази публикация.

Голяма реорганизация принуждава екипа ви да промени препратка към всички обекти в mydatabase2 в prodserver2.mydatabase2.

И така, вие заявявате sys.sql_modules с всички поява на mydatabase2 от mydatabase1 .

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

Сега изходът на скрипта по-горе ще изброи всички обекти, имащи препратки към mydatabase2 . Хубаво, а? И това ще помогне да се определи обхвата на работата, която трябва да бъде извършена.

Но това е само началото. Също така трябва да проверите дали има код във вашето клиентско приложение или друг код, който препраща към същия извън вашата база данни.

Количеството код, който е засегнат, показва колко голям е новият ви проблем.

Сега, ето още няколко лакомства за това какво се случва в този скрипт:

sys.sql_modules включват SQL обекти, които са модули, дефинирани от SQL, като изгледи, съхранени процедури, функции и т.н.
Име колоната е мястото, където е името на обекта.
Кодът на SQL за обекта е в дефиницията колона sys.sql_modules .
sys.all_objects включете всички обекти във вашата база данни като таблици, изгледи и т.н.
Взехме type_desc колона, за да определите какъв тип обект е (изглед, съхранена процедура и т.н.)
къде клаузата филтрира заявката за всеки SQL код, който включва препратка към mydatabase2 .
За да имате задоволителен резултат с помощта на скрипта по-горе, трябва да имате разрешение за всички обекти. За това се консултирайте с вашия администратор на база данни или някой с подобна роля. Можете също да проверите това.

Сега, когато знаете как да получите обхвата на работата си, е време да го поправите.

Как да поправите тази каша в кода, така че да не се повтори

Добре. Трябва да направя признание.

Използването на синоними на SQL Server само ще намали проблемите ви до минимум, но не и ще ги премахне.

Сега, когато вече не е на път, ето добрата новина:Ако имате 10 препратки към отдалечен обект, преди да използвате синоними, вие променяте всички 10. Но след като започнете да използвате синоним за този отдалечен обект, вместо да променяте 10 събития, променяте само 1. Нищо повече.

Ето стъпките за коригиране на това с помощта на синоними:

Създайте синоним за всеки от отдалечените обекти. Така че вместо prodserver2.mydatabase2.schema1.object1 можете да се позовавате на него, като използвате синоним.
Променете препратките към всеки обект в негов синоним.

По-късно ще разберете подробностите за това как да направите това.

Вземането за вкъщи:

Синонимите осигуряват слой на абстракция за защита на препратките към базови обекти от всяка част от вашия код, независимо дали във вашата база данни, клиентско приложение или навсякъде другаде. Така че можете да се радвате, когато настъпи друга промяна, независимо дали е прехвърляне на обект или преименуване.

2. Можете да създавате синоними на SQL Server за повечето обекти

След това нека да разберем кои обекти могат да имат синоними?

Таблици
Прегледи
Съхранени процедури
Функции

Сега, когато знаете типовете обекти, може да имате представа какво можете да правите със синоними. Нека станем по-конкретни.

3. Можете да издавате подходящи команди за синоним на обект

Трето, ето някои специфични команди за всеки тип обект.

Таблици

Доколкото можете да направите SELECT, INSERT, UPDATE и DELETE към таблица, можете да направите същото и с нейния синоним.

Така че вместо:

SELECT * FROM prodserver2.mydatabase2.schema1.table1

Можете да имате по-къса версия, която ще бъде устойчива на следващата промяна:

SELECT * FROM synonym1

Тъй като случаят е такъв, можете да направите и това:

UPDATE synonym1
SET column1 = <value>

Същото важи и за INSERT и DELETE.

Въпреки това, моля, имайте предвид следното:

Вмъкването на нов запис чрез синоним ще добави нов запис към основната таблица. В нашия случай, prodserver2.mydatabase2.schema1.table1 .
Актуализирането и изтриването ще имат същия ефект.

Досега показвахме само DML команди. Какво ще кажете за DDL команди като DROP?

За съжаление не можете да ги изпълните. Ето причината:

Изтриването на синоним няма да изпусне основната таблица. Ще изпусне синонима. Ще се впусна в подробности за това след малко.

Но ето още нещо, което можете да направите със SQL Server Синоними на таблици:JOIN.

Колко удобно може да бъде това? Вместо да издавате това:

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

Можете да извършите това:

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

Това по-просто ли е? Разбира се!

Съхранени процедури

Една подходяща команда, която можете да направите със синоним на съхранена процедура, е EXEC.

Така че, вместо да извиквате отдалечена процедура като тази:

EXEC prodserver2.mydatabase2.schema1.spProcedure1

Можете да създадете синоним за процедурата по-горе. Нека го наречем synProcedure1 . И го извикайте по следния начин:

EXEC synProcedure1

Да продължим ли? Можете да направите почти същото с VIEWS и FUNCTIONS. Разбира се, ако имате необходимите разрешения. Но първо, нека обсъдим как да създадем синоними на SQL Server.

4. Можете да започнете своето търсене със SQL Server Синоними със CREATE

Стигнахме до точката как можете да създавате синоними. Ето как можем да го направим с помощта на T-SQL за таблица:

CREATE SYNONYM synonym1 FOR prodserver2.mydatabase2.schema1.table1

Но имайте предвид това предупреждение:

Проверка за съществуването и разрешението за mydatabase2.schema1.table1 в prodserver2 се отлага до време на изпълнение.

Това означава, че няма да знаете, ако:

2-та сървъра (prodserver1 и prodserver2 ) вече са свързани.
базата данни mydatabase2 , схемасхема1 , и таблицата таблица1 действително съществуват.
достъпът ви до тези ресурси е разрешен.

Така че, след като създадете синонима, тествайте го, като изпълните командите, които очаквате да работят.

И със съхранените процедури, изгледи и функции трябва да действате по същия начин.

Но това не е всичко. Ако можем да създадем синоним, можем да го изтрием и с помощта на:

DROP SYNONYM synonym1

И ето още едно предупреждение:Тъй като можете да махнете синоними по всяко време, препратките към изпуснати синоними ще се проверяват само по време на изпълнение.

Затова преди да пуснете синоним, проверете sys.sql_modules защото ако има някакви препратки към него.

Използване на SQL Server Management Studio (SSMS) за създаване и премахване на синоними

Досега използвахме T-SQL за създаване и пускане на синоними на SQL Server. Може да предпочетете да използвате графичен интерфейс, когато правите същото.

Нека топката се търкаля.

Създаване на синоними

Ако въвеждането на команди не ви харесва, ето стъпките, които трябва да следвате, когато става въпрос за създаване на синоними:

Изпълнете SSMS и влезте във вашия SQL сървър.
Потърсете базата данни, където искате да създадете синоним.
Разгънете го.
Щракнете с десния бутон върху Синонимите папка и изберете Нов синоним .
Попълнете формуляра с информацията, необходима за синоними, включително име, схема и т.н.
Щракнете върху OK .

По-долу е екранна снимка на формуляра в SSMS:

Отпадане на синоними

Говорейки за предпочитания, въвеждането на команди за създаване на синоними е моето нещо. Но пускането им по желание е по-лесно от въвеждането на командите. Разбира се, това е само моето желание. Както и да е, по-долу са стъпките, които трябва да следвате, когато пускате синоним:

Изпълнете SSMS и влезте във вашия SQL сървър.
Потърсете базата данни, където се намира синонимът, който искате да премахнете.
Разгънете го.
Разгънете Синонимите папка.
Потърсете синоним, който искате да премахнете.
Щракнете с десния бутон върху синонима, който искате да пуснете, и изберете Изтриване .
Щракнете върху OK .

За да обобщите стъпките по-горе, просто щракнете с десния бутон върху синонима, за да го пуснете, след което изберете Изтриване и накрая щракнете върху OK .

По-долу е екранна снимка на прозореца, който ще се появи преди потвърждаване на изтриването:

5. Можете да защитите синоними на SQL Server

С помощта на GRANT, DENY или REVOKE можете да контролирате достъпа до синоним.

Да ПРЕДОСТАВЯ разрешение SELECT на синоним синоним1 на потребител на име testuser , правите както следва:

GRANT SELECT ON synonym1 to testuser

Други разрешения, които можете да добавите или премахнете от синоним, са следните:

КОНТРОЛ
ИЗПЪЛНЕНИЕ
АКТУАЛИЗИРАНЕ
ВМЪКНЕТЕ
ИЗТРИВАНЕ
ПРЕГЛЕД ДЕФИНИЦИЯ
ВЗЕМЕТЕ СОБСТВЕНОСТ

6. Не можете да намерите тази таблица, изглед или процедура? Може да е синоним

Един от проблемите, които новодошлият във вашия екип може да изпита е „липсваща“ таблица, изглед, процедура или функция. Разбира се, ако SELECT е издаден на обект, това може да е таблица или изглед. Но той не може да го намери в списъка с таблици или в списъка с изгледи. И ако преди това не е използвал синоними на SQL Server, това е допълнителен проблем.

Липса на ориентация, пропуск в документацията или пропуск във вашите стандарти могат да бъдат приведени в ред. Ето един изискан скрипт, който ще ви помогне да представите списъка със синоними и неговия основен обект на новия ви член на екипа:

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

„Липсващ“ обект? Вече не, ако е синоним.

Но преди да се вълнувате да изпълнявате този скрипт, ето още няколко неща, които трябва да вземете предвид:

sys.синоними е мястото, където всички синоними на SQL Server са дефинирани в текущата база данни.
Взехме описанията на типовете и типовете (тип и type_desc съответно) в sys.all_objects . Ако имате по-добра идея, освен да ги присъедините с подзаявка, моля, уведомете ме.
OBJECTPROPERTYEX се използва за получаване на типа на основния обект, ако това е таблица, съхранена процедура или друго.
Накрая, ако нямате минималното разрешение, необходимо за изпълнение на този скрипт и получаване на желания резултат, е време да се сприятелите с вашия DBA или някой с подобна роля:)

Но може би се чудите защо да правите всичко това, ако няма да работи добре?

7. Ще повлияят ли синонимите на SQL Server върху производителността?

Това е обща грижа. И за да разберем какво се случва зад кулисите, нека да разгледаме обобщението на това, което ще се случи в плана за изпълнение:

При изпълнение на най-простия код със синоним (напр. SELECT * от синоним1), SQL Server ще влезе във фаза на обвързване, при която основният обект ще замени синонима.
След това какъвто и най-добрият план за оптимизация да има за изпълнение на команда към базовия обект, той ще бъде същият.

Ето някои въпроси и отговори относно 2-те твърдения по-горе:

Колко време SQL Server изпълнява фазата на обвързване? ОТГОВОР:Не отнема много време. Обикновено се случва за миг.
Ако следващата стъпка използва същия най-добър план за оптимизация с базовия обект и заявката към базовия обект е „достатъчно бърза“, ще бъде ли по-бавна? ОТГОВОР:Не, защото ще използва същия план за изпълнение.
Какво ще кажете за удостоверяване от новия сървър? ОТГОВОР:Ако има леки забавяния, причинени от прехвърлянето на база данни към нов сървър, те не са причинени от синонима. Ефективност на заявката при извикването му с помощта на синоним или твърдо кодиране на server.database.schema.object трябва да е същото, защото синонимът е просто алтернативно име за основния обект. Решете бавната производителност от основния обект.

Но не ми вярвайте на думата. Трябва да го проверите сами с плана си за изпълнение на заявката и действителната производителност.

Заключение

Като цяло покрихме доста информация за синонимите на SQL Server, така че нека да обобщим.

Първо, синонимът е просто алтернативно име, което ще ви спести от промени в името на обекта и прехвърляне. Второ, добри кандидати за синоними са таблици, изгледи, съхранени процедури и функции. След това можете да правите команди, подходящи за неговия основен обект от синоним. Можете също да го подсигурите. След това, ако трябва да видите списъка със синоними, имате sys.synonyms да ти помогне. И накрая, производителността не би трябвало да създава големи проблеми, ако няма проблеми с производителността с базовия обект.

Така че защо не го изпробвате днес?

Какво мислиш? Кажете ни в коментарите.