7 fakta om SQL Server-synonymer du bör känna till

Innan SQL Server Synonyms dök upp ville alla förenkla och förbättra sin databasupplevelse.

Föreställ dig att du har en applikation med en databas som refererar till en annan databas från samma server. Sedan tvingar en stor omorganisation ditt team att överföra den andra databasen till en annan server.

Det råder ingen tvekan om att din ansökan kommer att gå sönder. Men vad gör du i så fall? Länka de två servrarna och hårdkoda alla referenser (igen) för att peka på den nya servern?

Du kan göra det om du vill och glömma om du bara har några eller ett dussin referenser till det. Men om en annan överföring eller ett byte av namn inträffar, måste du upprepa samma mardröm.

Ändå finns det ett bättre sätt att hantera detta.

Vi presenterar SQL Server-synonymer

Innan vi dyker in på vad du kan göra med SQL Server-synonymer, låt oss beskriva vad de är.

En synonym i något talat och skrivet språk hänvisar till ett ord eller en fras som har samma betydelse som ett annat ord eller en fras. Alltså ordet snygg är synonymen till vacker och attraktivt .

I likhet med vad vi vet om synonymer till ord och fraser, hänvisar SQL Server-synonymer till ett alternativt namn på ett databasobjekt som finns på en lokal eller fjärrserver. Läs mer här.

Som du kommer att se i följande fakta, kan SQL Server-synonymer göra ditt applikationsunderhåll mycket enklare.

Så låt oss komma igång!

1. SQL Server-synonymer kan förenkla ditt arbete när basobjekt överförs eller byter namn

För det första kommer de att rädda dig från besväret med kodändringar när en databas flyttas till en annan server eller byter namn av någon anledning. Låt oss hänvisa till scenariot vi nämnde i det här inlägget.

En större omorganisation tvingar ditt team att ändra en referens till alla objekt i mindatabas2 till prodserver2.mindatabas2.

Så du frågar sys.sql_modules med alla förekomster av mindatabas2 från min databas1 .

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

Nu kommer utdata från skriptet ovan att lista alla objekt som har referenser till mindatabas2 . Trevligt va? Och detta kommer att hjälpa till att definiera omfattningen av arbetet som måste göras.

Men det är bara början. Du måste också kontrollera om det finns kod i din klientapp eller någon annan kod som refererar till samma utanför din databas.

Mängden kod som påverkas visar hur stort ditt nya nummer är.

Nu, här är några fler tips om vad som händer i det skriptet:

sys.sql_modules inkludera SQL-objekt som är SQL-definierade moduler som vyer, lagrade procedurer, funktioner etc.
namnet kolumnen är där namnet på objektet är.
SQL-koden för objektet finns i definitionen kolumn sys.sql_modules .
sys.all_objects inkludera alla objekt i din databas som tabeller, vyer, etc.
Vi tog type_desc kolumn för att avgöra vilken typ av objekt det är (vy, lagrad procedur, etc.)
Den var klausul filtrerar frågan för alla SQL-koder som innehåller en referens till mindatabas2 .
För att få ett tillfredsställande resultat med skriptet ovan måste du ha behörighet för alla objekt. Kontrollera med din databasadministratör eller någon med liknande roll för detta. Du kan också kolla in det här.

Nu när du vet hur du får reda på omfattningen av ditt arbete är det dags att fixa det.

Hur man åtgärdar den här röran med kod så att det inte händer igen

Okej. Jag har en bekännelse att göra.

Att använda SQL Server-synonymer kommer bara att minska dina problem till ett minimum, men inte eliminera dem.

Nu när det är ur vägen, här är de goda nyheterna:Om du har 10 referenser till ett fjärrobjekt innan du använder synonymer, ändrar du alla 10. Men när du väl börjar använda en synonym för det fjärrobjektet, istället för att ändra 10 förekomster, du ändrar bara 1. Inget mer.

Nu, här är stegen för att fixa detta med synonymer:

Skapa en synonym för vart och ett av fjärrobjekten. Så istället för prodserver2.mydatabase2.schema1.object1 du kan referera till det med synonymen.
Ändra referenserna till varje objekt till dess synonym.

Senare kommer du att få reda på detaljerna om hur du gör detta.

The Takeaway:

Synonymer ger ett lager av abstraktion för att skydda referenser till basobjekt från vilken del av din kod som helst, oavsett om det är inuti din databas, klientapp eller någon annanstans. Så du kan glädja dig när en annan förändring sker, oavsett om det är en objektöverföring eller ett byte av namn.

2. Du kan skapa SQL Server-synonymer för de flesta objekt

Låt oss sedan ta reda på vilka objekt som kan ha synonymer?

Tabell
Visningar
Lagrade procedurer
Funktioner

Nu när du känner till objekttyperna kanske du har en uppfattning om vad du kan göra med synonymer. Låt oss bli mer specifika.

3. Du kan utfärda lämpliga kommandon för objektsynonymen

För det tredje, här är några specifika kommandon för varje objekttyp.

Tabell

Så mycket som du kan göra en SELECT, INSERT, UPDATE och DELETE till en tabell, kan du göra samma sak med dess synonym.

Så istället för:

SELECT * FROM prodserver2.mydatabase2.schema1.table1

Du kan ha en kortare version som är resistent mot nästa ändring:

SELECT * FROM synonym1

Eftersom så är fallet kan du också göra detta:

UPDATE synonym1
SET column1 = <value>

Och detsamma gäller INSERT och DELETE.

Var dock medveten om följande:

Om du infogar en ny post via en synonym kommer en ny post att läggas till i bastabellen. I vårt fall, prodserver2.mydatabase2.schema1.table1 .
Att uppdatera och ta bort kommer att ha samma effekt.

Hittills har vi bara visat DML-kommandon. Vad sägs om DDL-kommandon som DROP?

Tyvärr kan du inte utföra dem. Här är anledningen till:

Att släppa en synonym kommer inte att ta bort bastabellen. Det kommer att ta bort synonymen. Jag kommer att gå in i detalj om detta om ett ögonblick.

Men här är en sak till du kan göra med SQL Server Synonymer till tabeller:JOINs.

Hur bekvämt kan detta vara? Istället för att utfärda detta:

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

Du kan utföra detta:

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

Är det enklare? Visst!

Lagrade procedurer

Ett relevant kommando som du kan göra med en synonym till en lagrad procedur är EXEC.

Så istället för att anropa en fjärrprocedur så här:

EXEC prodserver2.mydatabase2.schema1.spProcedure1

Du kan skapa en synonym för proceduren ovan. Låt oss kalla det synProcedure1 . Och åberopa det så här:

EXEC synProcedure1

Ska vi fortsätta? Du kan göra ungefär samma sak med VISNINGAR och FUNKTIONER. Naturligtvis om du har de behörigheter som krävs. Men först, låt oss diskutera hur man skapar SQL Server-synonymer.

4. Du kan starta ditt uppdrag med SQL Server Synonymer med CREATE

Vi har kommit till punkten för hur du kan skapa synonymer. Så här kan vi göra det med T-SQL för en tabell:

CREATE SYNONYM synonym1 FOR prodserver2.mydatabase2.schema1.table1

Men notera denna varning:

Kontrollerar förekomsten av och behörighet för mydatabase2.schema1.table1 i prodserver2 skjuts upp till körning.

Det betyder att du inte vet om:

de två servrarna (prodserver1 och prodserver2 ) är redan länkade.
databasen mindatabas2 , schemat schema1 , och tabellen tabell1 faktiskt existerar.
din åtkomst till dessa resurser är tillåten.

Så, efter att ha skapat synonymen, testa den genom att köra de kommandon du förväntar dig att fungera.

Och med lagrade procedurer, vyer och funktioner bör du agera på samma sätt.

Men det är inte allt. Om vi kan skapa en synonym kan vi också ta bort den med:

DROP SYNONYM synonym1

Och här är en annan varning:Eftersom du kan släppa synonymer när som helst, kommer referenser till släppta synonymer endast att kontrolleras vid körning.

Så innan du släpper en synonym, kontrollera sys.sql_modules för om det finns några referenser till det.

Använda SQL Server Management Studio (SSMS) för att skapa och släppa synonymer

Hittills har vi använt T-SQL för att skapa och släppa SQL Server-synonymer. Du kanske föredrar att använda ett grafiskt gränssnitt när du gör detsamma.

Låt oss få bollen i rullning.

Skapa synonymer

Om det inte är din grej att skriva kommandona, här är stegen att följa när det gäller att skapa synonymer:

Kör SSMS och logga in på din SQL Server.
Leta efter databasen där du vill skapa en synonym.
Utöka det.
Högerklicka på Synonymer och välj Ny synonym .
Fyll i formuläret med den information som krävs för synonymer, inklusive namn, schema osv.
Klicka på OK .

Nedan finns en skärmdump av formuläret i SSMS:

Släpp synonymer

På tal om preferenser, att skriva kommandona för att skapa synonymer är min typ av grej. Men att släppa dem efter behag är enklare än att skriva kommandona. Naturligtvis, det är bara min smak. Hur som helst, nedan är stegen att följa när du släpper en synonym:

Kör SSMS och logga in på din SQL Server.
Leta efter databasen där synonymen du vill ta bort finns.
Utöka det.
Utöka Synonymer mapp.
Leta efter synonymen du vill släppa.
Högerklicka på den synonym du vill ta bort och välj Ta bort .
Klicka på OK .

För att sammanfatta stegen ovan, högerklicka helt enkelt på synonymen för att släppa och välj sedan Ta bort och slutligen klickar du på OK .

Nedan är en skärmdump av fönstret som visas innan du bekräftar raderingen:

5. Du kan säkra SQL Server-synonymer

Genom att använda GRANT, DENY eller REVOKE kan du kontrollera åtkomsten till en synonym.

Att GE en SELECT-behörighet till synonymen synonym1 till en användare som heter testuser , gör du så här:

GRANT SELECT ON synonym1 to testuser

Andra behörigheter som du kan lägga till eller ta bort från en synonym är följande:

KONTROLL
UTFÖR
UPPDATERA
INSERT
RADERA
VISA DEFINITION
TA ÄGANDE

6. Hittar du inte den tabellen, vyn eller proceduren? Det kan vara en synonym

Ett av problemen som en nykomling i ditt team kan uppleva är en "saknad" tabell, vy, procedur eller funktion. Om SELECT utfärdas på ett objekt kan det naturligtvis vara en tabell eller vy. Men han kan inte hitta det i tabelllistan eller visningslistan. Och om han inte använde SQL Server-synonymer tidigare, är det ett ytterligare problem.

Bristande orientering, en lucka i dokumentationen eller en lucka i dina standarder kan ordnas. Här är ett snyggt skript som hjälper dig att presentera listan över synonymer och dess basobjekt för din nya teammedlem:

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

Ett "saknat" föremål? Inte längre om det är en synonym.

Men innan du blir upphetsad att köra det här skriptet, här är några fler saker du bör ta hänsyn till:

sys.synonyms är där alla SQL Server-synonymer är definierade i den aktuella databasen.
Vi tog typerna och typbeskrivningarna (typ och type_desc respektive) i sys.all_objects . Om du har en bättre idé än att gå med dem med en underfråga, vänligen meddela mig.
OBJECTPROPERTYEX används för att hämta typen av basobjekt om det är en tabell, lagrad procedur eller annat.
Slutligen, om du inte har den minsta behörigheten som krävs för att köra det här skriptet och få önskad utdata, är det dags att bli vän med din DBA eller någon med en liknande roll:)

Men du kanske undrar, varför gör alla dessa om det inte fungerar bra?

7. Kommer SQL Server-synonymer att påverka prestanda?

Detta är ett vanligt bekymmer. Och för att konkretisera vad som händer bakom kulisserna, låt oss ta en titt på sammanfattningen av vad som kommer att hända i genomförandeplanen:

När du kör den enklaste koden med en synonym (t.ex. SELECT * från synonym1), kommer SQL Server att gå in i en bindningsfas där basobjektet ersätter synonymen.
Närnäst, oavsett den bästa optimeringsplanen som finns för att utföra ett kommando till basobjektet, kommer det att vara detsamma.

Här är några frågor och svar angående de två påståendena ovan:

Hur lång tid tar SQL Server bindningsfasen? SVAR:Det tar inte lång tid. Det händer vanligtvis på ett ögonblick.
Om nästa steg använder samma bästa optimeringsplan med basobjektet och frågan till basobjektet är "snabbt nog", blir det långsammare? SVAR:Nej, eftersom det kommer att använda samma utförandeplan.
Vad sägs om autentisering från den nya servern? SVAR:Om det finns några mindre förseningar orsakade av överföringen av en databas till en ny server, orsakas de inte av synonymen. Fråga prestanda för att anropa den med en synonym eller hårdkodning av server.database.schema.object bör vara densamma eftersom synonymen bara är ett alternativt namn för basobjektet. Lös den långsamma prestandan från basobjektet.

Men ta inte mitt ord för det. Du bör kontrollera det själv med din exekveringsplan och faktiska prestanda.

Slutsats

Allt som allt täckte vi ganska mycket information om SQL Server-synonymer, så låt oss sammanfatta.

För det första är en synonym helt enkelt ett alternativt namn som kommer att rädda dig från ändringar och överföringar av objektnamn. För det andra är bra kandidater för synonymer tabeller, vyer, lagrade procedurer och funktioner. Därefter kan du göra kommandon som är lämpliga för dess basobjekt från en synonym. Du kan säkra den också. Sedan, om du behöver se listan över synonymer, har du sys.synonyms att hjälpa dig. Slutligen bör prestanda inte vara något problem om det inte finns några prestandaproblem med basobjektet.

Så varför inte prova det idag?

Vad tror du? Låt oss veta i kommentarerna.