7 feiten over SQL Server-synoniemen die u moet kennen

Voordat SQL Server-synoniemen verschenen, wilde iedereen hun database-ervaring vereenvoudigen en verbeteren.

Stel je voor dat je een applicatie hebt met een database die verwijst naar een andere database van dezelfde server. Vervolgens dwingt een grote reorganisatie uw team om de andere database naar een andere server te verplaatsen.

Er is geen twijfel dat uw aanvraag zal breken. Maar wat gaat u in dat geval doen? Koppel de 2 servers en hardcode alle referenties (opnieuw) om naar de nieuwe server te verwijzen?

Je zou dat kunnen doen als je wilt en vergeten als je er maar een paar of een dozijn verwijzingen naar hebt. Maar als er nog een overdracht of een nieuwe naam plaatsvindt, moet je dezelfde nachtmerrie herhalen.

Toch is er een betere manier om hiermee om te gaan.

Introductie van SQL Server-synoniemen

Voordat we ingaan op wat u kunt doen met SQL Server-synoniemen, laten we beschrijven wat ze zijn.

Een synoniem in elke gesproken en geschreven taal verwijst naar een woord of zin die dezelfde betekenis heeft als een ander woord of een andere zin. Dus het woord prachtig is het synoniem voor mooi en aantrekkelijk .

Net als wat we weten over synoniemen van woorden en woordgroepen, verwijzen SQL Server-synoniemen naar een alternatieve naam van een databaseobject dat zich op een lokale of externe server bevindt. Lees hier meer.

Zoals u in de volgende feiten zult zien, kunnen SQL Server-synoniemen het onderhoud van uw applicatie een stuk eenvoudiger maken.

Dus laten we beginnen!

1. SQL Server-synoniemen kunnen uw werk vereenvoudigen wanneer basisobjecten worden overgedragen of hernoemd

Ten eerste besparen ze u de moeite van codewijzigingen wanneer een database om welke reden dan ook naar een andere server wordt verplaatst of hernoemd. Laten we verwijzen naar het scenario dat we in deze postopening noemden.

Een grote reorganisatie dwingt uw team om een verwijzing naar alle objecten in mijndatabase2 . te wijzigen in prodserver2.mydatabase2.

U zoekt dus naar sys.sql_modules met alle exemplaren van mijndatabase2 uit mijndatabase1 .

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 zal de uitvoer van het bovenstaande script alle objecten weergeven met verwijzingen naar mijndatabase2 . Leuk, hè? En dit zal helpen om de reikwijdte van het werk te bepalen dat moet worden gedaan.

Maar dat is nog maar het begin. U moet ook controleren of er code in uw client-app staat of een andere code die ernaar verwijst buiten uw database.

De hoeveelheid code die wordt beïnvloed, geeft aan hoe groot uw nieuwe probleem is.

Hier zijn nog een paar weetjes over wat er in dat script gebeurt:

sys.sql_modules omvatten SQL-objecten die door SQL gedefinieerde modules zijn, zoals views, opgeslagen procedures, functies, enz.
De naam kolom is waar de naam van het object staat.
De SQL-code voor het object staat in de definitie kolom met sys.sql_modules .
sys.all_objects neem alle objecten in uw database op, zoals tabellen, weergaven, enz.
We namen de type_desc kolom om te bepalen welk type object het is (weergave, opgeslagen procedure, enz.)
De waar clausule filtert de query op elke SQL-code die een verwijzing bevat naar mijndatabase2 .
Om een bevredigend resultaat te krijgen met het bovenstaande script, moet je toestemming hebben voor alle objecten. Neem hiervoor contact op met uw databasebeheerder of iemand met een vergelijkbare rol. Je kunt dit ook bekijken.

Nu je weet hoe je de reikwijdte van je werk kunt krijgen, is het tijd om het op te lossen.

Hoe deze puinhoop van code op te lossen, zodat het niet meer zal gebeuren

Oke. Ik moet een bekentenis afleggen.

Het gebruik van SQL Server-synoniemen zal uw problemen tot een minimum beperken, maar niet elimineren.

Nu het uit de weg is, is hier het goede nieuws:als u 10 verwijzingen naar een object op afstand heeft voordat u synoniemen gebruikt, wijzigt u alle 10. Maar zodra u een synoniem voor dat object op afstand begint te gebruiken, in plaats van 10 exemplaren te wijzigen, je verandert maar 1. Niets meer.

Dit zijn de stappen om dit op te lossen met behulp van synoniemen:

Maak een synoniem voor elk van de externe objecten. Dus in plaats van prodserver2.mydatabase2.schema1.object1 je kunt ernaar verwijzen met het synoniem.
Wijzig de verwijzingen naar elk object in zijn synoniem.

Later zul je ontdekken hoe je dit moet doen.

De afhaalmaaltijd:

Synoniemen bieden een abstractielaag om verwijzingen naar basisobjecten te beschermen vanuit elk deel van uw code, of dit nu in uw database, client-app of ergens anders is. U kunt dus blij zijn als er weer een wijziging plaatsvindt, of het nu gaat om een objectoverdracht of een hernoeming.

2. U kunt SQL Server-synoniemen maken voor de meeste objecten

Laten we vervolgens uitzoeken welke objecten synoniemen kunnen hebben?

Tafels
Beelden
Opgeslagen procedures
Functies

Nu u de objecttypen kent, heeft u misschien een idee van wat u met synoniemen kunt doen. Laten we specifieker worden.

3. U kunt de juiste opdrachten geven voor het objectsynoniem

Ten derde zijn hier enkele specifieke commando's voor elk objecttype.

Tafels

Zoveel als u een SELECT, INSERT, UPDATE en DELETE kunt doen voor een tabel, kunt u hetzelfde doen met het synoniem ervan.

Dus in plaats van:

SELECT * FROM prodserver2.mydatabase2.schema1.table1

U kunt een kortere versie hebben die bestand is tegen de volgende wijziging:

SELECT * FROM synonym1

Aangezien dit het geval is, kunt u ook dit doen:

UPDATE synonym1
SET column1 = <value>

En hetzelfde geldt voor INSERT en DELETE.

Houd echter rekening met het volgende:

Als u een nieuw record invoegt via een synoniem, wordt een nieuw record aan de basistabel toegevoegd. In ons geval prodserver2.mydatabase2.schema1.table1 .
Bijwerken en verwijderen heeft hetzelfde effect.

Tot nu toe hebben we alleen DML-commando's getoond. Hoe zit het met DDL-commando's zoals DROP?

Helaas kun je ze niet uitvoeren. Dit is de reden waarom:

Als u een synoniem laat vallen, wordt de basistabel niet verwijderd. Het zal het synoniem laten vallen. Ik zal hier zo in detail op ingaan.

Maar hier is nog iets dat u kunt doen met SQL Server-synoniemen van tabellen:JOINs.

Hoe handig kan dit zijn? In plaats van dit uit te geven:

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

U kunt dit doen:

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

Is dat eenvoudiger? Zeker!

Opgeslagen procedures

Een relevante opdracht die u kunt doen met een synoniem van een opgeslagen procedure is EXEC.

Dus, in plaats van een procedure op afstand als deze aan te roepen:

EXEC prodserver2.mydatabase2.schema1.spProcedure1

U kunt een synoniem maken voor de bovenstaande procedure. Laten we het synProcedure1 . noemen . En roep het op deze manier aan:

EXEC synProcedure1

Zullen we verder gaan? U kunt ongeveer hetzelfde doen met VIEWs en FUNCTIONs. Natuurlijk, als u over de vereiste machtigingen beschikt. Maar laten we eerst bespreken hoe u SQL Server-synoniemen kunt maken.

4. U kunt uw zoektocht beginnen met SQL Server-synoniemen met CREATE

We hebben het punt bereikt waarop u synoniemen kunt maken. Hier is hoe we het kunnen doen met T-SQL voor een tabel:

CREATE SYNONYM synonym1 FOR prodserver2.mydatabase2.schema1.table1

Maar let op dit voorbehoud:

Controleren op het bestaan van en toestemming voor mydatabase2.schema1.table1 in prodserver2 wordt uitgesteld tot runtime.

Dat betekent dat je niet weet of:

de 2 servers (prodserver1 en prodserver2 ) zijn al gekoppeld.
de database mijndatabase2 , het schema schema1 , en de tabel tabel1 echt bestaan.
je toegang tot die bronnen is toegestaan.

Dus, na het aanmaken van het synoniem, test het door de commando's uit te voeren waarvan je verwacht dat ze werken.

En met opgeslagen procedures, weergaven en functies zou u op dezelfde manier moeten handelen.

Maar dat is niet alles. Als we een synoniem kunnen maken, kunnen we het ook verwijderen met:

DROP SYNONYM synonym1

En hier is nog een waarschuwing:aangezien u synoniemen op elk moment kunt verwijderen, worden verwijzingen naar verwijderde synoniemen alleen tijdens runtime gecontroleerd.

Dus voordat u een synoniem laat vallen, controleert u sys.sql_modules voor als er verwijzingen naar zijn.

SQL Server Management Studio (SSMS) gebruiken om synoniemen te maken en te verwijderen

Tot nu toe hebben we T-SQL gebruikt om SQL Server-synoniemen te maken en te verwijderen. U kunt er de voorkeur aan geven om een grafische interface te gebruiken wanneer u hetzelfde doet.

Laten we de bal aan het rollen brengen.

Synoniemen maken

Als het typen van de commando's niet jouw ding is, zijn hier de stappen die je moet volgen als het gaat om het maken van synoniemen:

Voer SSMS uit en log in op uw SQL Server.
Zoek de database waarin u een synoniem wilt maken.
Breid het uit.
Klik met de rechtermuisknop op de Synoniemen map en selecteer Nieuw synoniem .
Vul het formulier in met de informatie die nodig is voor synoniemen, inclusief de naam, het schema, enz.
Klik op OK .

Hieronder is een screenshot van het formulier in SSMS:

Synoniemen laten vallen

Over voorkeuren gesproken, het typen van de commando's voor het maken van synoniemen is mijn soort ding. Maar ze naar believen laten vallen is eenvoudiger dan het typen van de opdrachten. Dat is natuurlijk gewoon mijn smaak. Hoe dan ook, hieronder zijn de stappen die u moet volgen bij het verwijderen van een synoniem:

Voer SSMS uit en log in op uw SQL Server.
Zoek naar de database waar het synoniem dat u wilt verwijderen zich bevindt.
Breid het uit.
Breid de Synoniemen uit map.
Zoek naar het synoniem dat u wilt verwijderen.
Klik met de rechtermuisknop op het synoniem dat u wilt verwijderen en selecteer Verwijderen .
Klik op OK .

Om de bovenstaande stappen samen te vatten, klikt u met de rechtermuisknop op het synoniem om te verwijderen en selecteert u vervolgens Verwijderen en klik ten slotte op OK .

Hieronder ziet u een schermafbeelding van het venster dat verschijnt voordat de verwijdering wordt bevestigd:

5. U kunt SQL Server-synoniemen beveiligen

Met GRANT, DENY of REVOKE kun je de toegang tot een synoniem beheren.

Om een SELECT-toestemming te verlenen aan het synoniem synoniem1 aan een gebruiker met de naam testuser , doet u het volgende:

GRANT SELECT ON synonym1 to testuser

Andere rechten die u kunt toevoegen aan of verwijderen uit een synoniem zijn de volgende:

CONTROLE
UITVOEREN
UPDATE
INSERT
VERWIJDEREN
DEFINITIE BEKIJKEN
EIGENDOM NEMEN

6. Kunt u die tabel, weergave of procedure niet vinden? Het kan een synoniem zijn

Een van de problemen die een nieuwkomer in uw team kan ervaren, is een "ontbrekende" tabel, weergave, procedure of functie. Als SELECT op een object wordt uitgegeven, kan het natuurlijk een tabel of weergave zijn. Maar hij kan het niet vinden in de lijst met tabellen of weergaven. En als hij niet eerder SQL Server-synoniemen gebruikte, is dat een bijkomend probleem.

Gebrek aan oriëntatie, een hiaat in de documentatie, of een hiaat in uw standaarden kan op orde worden gebracht. Hier is een handig script waarmee u de lijst met synoniemen en het basisobject kunt presenteren aan uw nieuwe teamlid:

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

Een "ontbrekend" object? Niet meer als het een synoniem is.

Maar voordat je enthousiast wordt over het uitvoeren van dit script, zijn hier nog een paar dingen waar je rekening mee moet houden:

sys.synoniemen is waar alle SQL Server-synoniemen zijn gedefinieerd in de huidige database.
We hebben de typen en typebeschrijvingen genomen (type en type_desc respectievelijk) in sys.all_objects . Als je een beter idee hebt dan ze samen te voegen met een subquery, laat het me dan weten.
OBJECTPROPERTYEX wordt gebruikt om het type van het basisobject te krijgen als het een tabel, een opgeslagen procedure of iets anders is.
Ten slotte, als je niet de minimale toestemming hebt die nodig is om dit script uit te voeren en de gewenste uitvoer te krijgen, is het tijd om vrienden te maken met je DBA of iemand met een vergelijkbare rol :)

Maar je vraagt je misschien af, waarom zou je dit allemaal doen als het niet goed zal presteren?

7. Hebben SQL Server-synoniemen invloed op de prestaties?

Dit is een gemeenschappelijke zorg. En om in te schatten wat er achter de schermen gebeurt, laten we eens kijken naar de samenvatting van wat er zal gebeuren in het uitvoeringsplan:

Bij het uitvoeren van de eenvoudigste code met een synoniem (bijv. SELECT * van synoniem1), zal SQL Server een bindingsfase ingaan waarin het basisobject het synoniem zal vervangen.
Vervolgens, wat het beste optimalisatieplan is dat er is voor het uitvoeren van een commando naar het basisobject, het zal hetzelfde zijn.

Hier zijn enkele vragen en antwoorden met betrekking tot de 2 bovenstaande uitspraken:

Hoe lang duurt de bindingsfase van SQL Server? ANTWOORD:Het duurt niet lang. Het gebeurt meestal in een oogwenk.
Als de volgende stap hetzelfde beste optimalisatieplan met het basisobject gebruikt en de query naar het basisobject "snel genoeg" is, zal het dan langzamer zijn? ANTWOORD:Nee, omdat het hetzelfde uitvoeringsplan zal gebruiken.
Hoe zit het met authenticatie vanaf de nieuwe server? ANTWOORD:Als er enkele kleine vertragingen zijn die worden veroorzaakt door de overdracht van een database naar een nieuwe server, worden deze niet veroorzaakt door het synoniem. Query uitvoeren op het aanroepen van het met behulp van een synoniem of hardcoderen van het server.database.schema.object moet hetzelfde zijn omdat het synoniem slechts een alternatieve naam is voor het basisobject. Los de trage prestaties van het basisobject op.

Maar geloof me niet op mijn woord. U moet het zelf controleren met uw query-uitvoeringsplan en werkelijke prestaties.

Conclusie

Al met al hebben we vrij veel informatie over SQL Server-synoniemen behandeld, dus laten we het samenvatten.

Ten eerste is een synoniem gewoon een alternatieve naam die u zal behoeden voor wijzigingen en overdrachten van objectnamen. Ten tweede zijn tabellen, views, opgeslagen procedures en functies goede kandidaten voor synoniemen. Vervolgens kunt u vanuit een synoniem opdrachten uitvoeren die geschikt zijn voor het basisobject. Je kunt het ook beveiligen. Als u vervolgens de lijst met synoniemen wilt zien, heeft u sys.synoniemen om je te helpen. Ten slotte zouden de prestaties niet zo'n probleem moeten zijn als er geen prestatieproblemen zijn met het basisobject.

Dus waarom zou u het vandaag niet proberen?

Wat denk je? Laat het ons weten in de reacties.