7 fakta om SQL Server-synonymer, du bør kende

Før SQL Server Synonyms dukkede op, ønskede alle at forenkle og forbedre deres databaseoplevelse.

Forestil dig, at du har et program med en database, der refererer til en anden database fra den samme server. Derefter tvinger en større omorganisering dit team til at overføre den anden database til en anden server.

Der er ingen tvivl om, at din ansøgning går i stykker. Men hvad vil du i så fald gøre? Forbind de 2 servere og indkode alle referencerne (igen) for at pege på den nye server?

Du kan gøre det, hvis du vil og glemme, hvis du kun har et par eller et dusin referencer til det. Men hvis der sker en anden overførsel eller et omdøbning, bliver du nødt til at gentage det samme mareridt.

Ikke desto mindre er der en bedre måde at håndtere dette på.

Introduktion af SQL Server-synonymer

Før vi dykker ind i, hvad du kan gøre med SQL Server-synonymer, lad os beskrive, hvad de er.

Et synonym i ethvert talt og skrevet sprog refererer til et ord eller en sætning, der har samme betydning som et andet ord eller en sætning. Altså ordet smuk er synonymet til smuk og attraktiv .

I lighed med, hvad vi ved om synonymer af ord og sætninger, refererer SQL Server Synonymer til et alternativt navn på et databaseobjekt, der ligger på en lokal eller fjernserver. Læs mere her.

Som du vil se i de følgende fakta, kan SQL Server-synonymer gøre din applikationsvedligeholdelse meget nemmere.

Så lad os komme i gang!

1. SQL Server-synonymer kan forenkle dit arbejde, når basisobjekter overføres eller omdøbes

For det første vil de redde dig fra besværet med kodeændringer, når en database flyttes til en anden server eller omdøbes uanset årsagen. Lad os henvise til det scenarie, vi nævnte i dette indlæg.

En større omorganisering tvinger dit team til at ændre en reference til alle objekter i mindatabase2 ind i prodserver2.mydatabase2.

Så du forespørger sys.sql_modules med alle forekomster af mindatabase2 fra min database1 .

BRUG mydatabase1GOSELECT b.name,a.definition,b.type_descFROM sys.sql_modules aINNER JOIN sys.all_objects b på a.object_id =b.object_idWHERE a.definition som '%mydatabase2%'GO

Nu vil outputtet af scriptet ovenfor liste alle objekter med referencer til mindatabase2 ned. . Dejligt, hva'? Og dette vil hjælpe med at definere omfanget af det arbejde, der skal udføres.

Men det er kun begyndelsen. Du skal også kontrollere, om der er kode i din klientapp eller en anden kode, der refererer til det samme uden for din database.

Mængden af kode, der påvirkes, viser, hvor stort dit nye problem er.

Nu, her er et par flere ting om, hvad der foregår i det script:

sys.sql_modules inkludere SQL-objekter, der er SQL-definerede moduler som visninger, lagrede procedurer, funktioner osv.
navnet kolonne er, hvor navnet på objektet er.
SQL-koden for objektet er i definitionen kolonne af sys.sql_modules .
sys.all_objects inkludere alle objekter i din database som tabeller, visninger osv.
Vi tog type_desc kolonne for at bestemme, hvilken type objekt det er (visning, lagret procedure osv.)
Det hvor klausul filtrerer forespørgslen efter enhver SQL-kode, der indeholder en reference til mindatabase2 .
For at få et tilfredsstillende resultat ved at bruge scriptet ovenfor, skal du have tilladelse til alle objekterne. Spørg din databaseadministrator eller en anden med en lignende rolle for dette. Du kan også tjekke dette ud.

Nu hvor du ved, hvordan du får omfanget af dit arbejde, er det tid til at rette det.

Sådan rettes dette rod med kode, så det ikke sker igen

Okay. Jeg har en tilståelse at komme med.

Brug af SQL Server-synonymer vil kun reducere dine problemer til et minimum, men ikke eliminere dem.

Nu hvor det er af vejen, her er de gode nyheder:Hvis du har 10 referencer til et eksternt objekt, før du bruger synonymer, ændrer du alle 10. Men når du først begynder at bruge et synonym for det eksterne objekt, i stedet for at ændre 10 forekomster, du ændrer kun 1. Ikke mere.

Her er trinene til at løse dette ved hjælp af synonymer:

Opret et synonym for hvert af de eksterne objekter. Så i stedet for prodserver2.mydatabase2.schema1.object1 du kan henvise til det ved at bruge synonymet.
Rediger referencerne til hvert objekt til dets synonym.

Senere vil du finde ud af detaljerne om, hvordan du gør dette.

The Takeaway:

Synonymer giver et lag af abstraktion for at beskytte referencer til basisobjekter fra enhver del af din kode, uanset om det er inde i din database, klientapp eller andre steder. Så du kan glæde dig, når der sker endnu en ændring, uanset om det er en objektoverførsel eller et omdøbning.

2. Du kan oprette SQL Server-synonymer for de fleste objekter

Lad os derefter finde ud af, hvilke objekter der kan have synonymer?

Tabeller
Visninger
Lagrede procedurer
Funktioner

Nu hvor du kender objekttyperne, har du måske en idé om, hvad du kan gøre med synonymer. Lad os blive mere specifikke.

3. Du kan udstede passende kommandoer til objektsynonymet

For det tredje er her nogle specifikke kommandoer for hver objekttype.

Tabeller

Så meget som du kan gøre en SELECT, INSERT, UPDATE og DELETE til en tabel, kan du gøre det samme med dens synonym.

Så i stedet for:

VÆLG * FRA prodserver2.mydatabase2.schema1.table1

Du kan have en kortere version, der vil være modstandsdygtig over for den næste ændring:

VÆLG * FRA synonym1

Da dette er tilfældet, kan du også gøre dette:

OPDATERING synonym1SET kolonne1 =

 
 Og det samme gælder for INSERT og DELETE.
 
 Vær dog opmærksom på følgende:
  Hvis du indsætter en ny post gennem et synonym, tilføjes en ny post til basistabellen. I vores tilfælde, prodserver2.mydatabase2.schema1.table1 .
 Opdatering og sletning vil have samme effekt.
 
 
 Indtil videre har vi kun vist DML-kommandoer. Hvad med DDL-kommandoer som DROP?
 
 Desværre kan du ikke udføre dem. Her er grunden til:
 
 Sletning af et synonym vil ikke tabe basistabellen. Det vil droppe synonymet. Jeg vil gå i detaljer om dette om et øjeblik.
 
 Men her er en ting mere, du kan gøre ved SQL Server Synonymer af tabeller:JOINs.
 
 Hvor praktisk kan dette være? I stedet for at udstede dette:
 VÆLG a.column1,b.column1FROM table3 aINNER JOIN prodserver2.mydatabase2.schema1.table1 b on a.id =b.id 
 
 Du kan udføre dette:
 VÆLG a.column1,b.column1FROM table3 aINNER JOIN synonym1 b på a.id =b.id 
 
 Er det nemmere? Selvfølgelig!
 Lagrede procedurer
 
 En relevant kommando, du kan udføre med et synonym for en lagret procedure, er EXEC.
 
 Så i stedet for at påberåbe sig en fjernprocedure som denne:
 EXEC prodserver2.mydatabase2.schema1.spProcedure1 
 
 Du kan oprette et synonym til ovenstående procedure. Lad os kalde det synProcedure1 . Og påberåb det på denne måde:
 EXEC synProcedure1 
 
 Skal vi fortsætte? Du kan gøre meget det samme med VIEWS og FUNCTIONS. Selvfølgelig, hvis du har de nødvendige tilladelser. Men lad os først diskutere, hvordan man opretter SQL Server-synonymer.
 4. Du kan starte din Quest med SQL Server Synonymer med CREATE
 
 Vi er nået til punktet om, hvordan du kan oprette synonymer. Sådan kan vi gøre det ved at bruge T-SQL til en tabel:
 OPRET SYNONYM synonym1 FOR prodserver2.mydatabase2.schema1.table1 
 
 Men vær opmærksom på denne advarsel:
 
 Kontrollerer eksistensen af og tilladelsen til mydatabase2.schema1.table1 i prodserver2 er udsat til køretid.
 
 Det betyder, at du ikke ved, om:
  de 2 servere (prodserver1 og prodserver2 ) er allerede linket.
 databasen mindatabase2 , skemaet skema1 , og tabellen tabel1 faktisk eksisterer.
 din adgang til disse ressourcer er tilladt.
 
 
 Så efter at have oprettet synonymet, test det ved at køre de kommandoer, du forventer skal virke.
 
 Og med lagrede procedurer, visninger og funktioner bør du handle på samme måde.
 
 Men det er ikke alt. Hvis vi kan oprette et synonym, kan vi også slette det ved at bruge:
 DROP SYNONYM synonym1 
 
 Og her er en anden advarsel:Da du kan droppe synonymer når som helst, vil referencer til mistede synonymer kun blive kontrolleret under kørsel.
 
 Så før du dropper et synonym, skal du tjekke sys.sql_modules for hvis der er nogen henvisninger til det.
 Brug af SQL Server Management Studio (SSMS) til at oprette og slette synonymer
 
 Indtil videre har vi brugt T-SQL til at oprette og slippe SQL Server Synonymer. Du foretrækker måske at bruge en grafisk grænseflade, når du gør det samme.
 
 Lad os få bolden til at rulle.
 Oprettelse af synonymer
 
 Hvis det ikke er noget for dig at skrive kommandoerne, er her de trin, du skal følge, når det kommer til at oprette synonymer:
  Kør SSMS og log ind på din SQL Server.
 Kig efter den database, hvor du vil oprette et synonym.
 Udvid den.
 Højreklik på Synonymer mappe, og vælg Nyt synonym .
 Udfyld formularen med de oplysninger, der kræves for synonymer, herunder navn, skema osv.
 Klik på OK .
 
 
 Nedenfor er et skærmbillede af formularen i SSMS:
  Slet synonymer
 
 Apropos præferencer, så er det min slags ting at skrive kommandoerne til at oprette synonymer. Men at slippe dem efter behag er nemmere end at skrive kommandoerne. Det er selvfølgelig lige min smag. Uanset hvad, nedenfor er de trin, du skal følge, når du dropper et synonym:
  Kør SSMS og log ind på din SQL Server.
 Kig efter databasen, hvor det synonym, du vil slette, er placeret.
 Udvid den.
 Udvid Synonymer mappe.
 Kig efter det synonym, du vil slette.
 Højreklik på det synonym, du vil slette, og vælg Slet .
 Klik på OK .
 
 
 For at opsummere ovenstående trin skal du blot højreklikke på synonymet for at slippe og derefter vælge Slet og til sidst skal du klikke på OK .
 
 Nedenfor er et skærmbillede af vinduet, der vises før bekræftelse af sletning:
   5. Du kan sikre SQL Server-synonymer
 
 Ved at bruge GRANT, DENY eller REVOKE kan du kontrollere adgangen til et synonym.
 
 At GIVE en SELECT-tilladelse til synonymet synonym1 til en bruger ved navn testuser , gør du som følger:
 GIV SELECT ON synonym1 til testbruger 
 
 Andre tilladelser, du kan tilføje til eller fjerne fra et synonym, er følgende:
  KONTROL
 UDFØR
 OPDATERING
 INDSÆT
 SLET
 SE DEFINITION
 TAG EJERSKAB
 
 6. Kan du ikke finde den tabel, visning eller procedure? Det kan være et synonym
 
 Et af de problemer, en nybegynder i dit team kan opleve, er et "manglende" bord, visning, procedure eller funktion. Hvis SELECT er udstedt på et objekt, kan det selvfølgelig være en tabel eller en visning. Men han kan ikke finde det i tabellisten eller visningslisten. Og hvis han ikke brugte SQL Server Synonyms før, er det et yderligere problem.
 
 Manglende orientering, et hul i dokumentationen eller et hul i dine standarder kan bringes i orden. Her er et smart script, der hjælper dig med at præsentere listen over synonymer og dets basisobjekt for dit nye teammedlem:
 VÆLG a.[navn],a.[base_object_name],OBJECTPROPERTYEX(OBJECT_ID(a.[navn]), 'BaseType') som BaseType,b.type_descFROM sys.synonyms aINNER JOIN (SELECT DISTINCT type, type_desc fra sys.all_objects) b på CONVERT(varchar(2),OBJECTPROPERTYEX(OBJECT_ID(a.[navn]), 'BaseType')) =b.type  
 Et "manglende" objekt? Ikke længere, hvis det er et synonym.
 
 Men før du bliver begejstret for at køre dette script, er her et par flere ting, du bør tage højde for:
  sys.synonyms er, hvor alle SQL Server-synonymer er defineret i den aktuelle database.
 Vi tog typerne og typebeskrivelserne (type og type_desc henholdsvis) i sys.all_objects . Hvis du har en bedre idé end at slutte sig til dem med en underforespørgsel, så lad mig det vide.
 OBJECTPROPERTYEX bruges til at få typen af basisobjektet, hvis det er en tabel, lagret procedure eller andet.
 Til sidst, hvis du ikke har den minimumstilladelse, der kræves for at udføre dette script og få det ønskede output, er det tid til at blive venner med din DBA eller en person med en lignende rolle:)
 
 
 Men du spekulerer måske på, hvorfor gøre alle disse, hvis det ikke fungerer godt?
 7. Vil SQL Server-synonymer påvirke ydeevnen?
 
 Dette er en fælles bekymring. Og for at uddybe, hvad der foregår bag kulisserne, så lad os tage et kig på opsummeringen af, hvad der vil ske i udførelsesplanen:
  Når du udfører den enkleste kode med et synonym (f.eks. SELECT * fra synonym1), vil SQL Server gå ind i en bindingsfase, hvor basisobjektet erstatter synonymet.
 Dernæst, uanset hvilken bedste optimeringsplan der er for at udføre en kommando til basisobjektet, vil den være den samme.
 
 
 Her er nogle spørgsmål og svar vedrørende de 2 udsagn ovenfor:
  Hvor længe udfører SQL Server bindingsfasen? SVAR:Det tager ikke lang tid. Det sker normalt på et øjeblik.
 Hvis det næste trin bruger den samme bedste optimeringsplan med basisobjektet, og forespørgslen til basisobjektet er "hurtig nok", vil det så være langsommere? SVAR:Nej, fordi den vil bruge den samme udførelsesplan.
 Hvad med godkendelse fra den nye server? SVAR:Hvis der er nogle små forsinkelser forårsaget af overførslen af en database til en ny server, er de ikke forårsaget af synonymet. Forespørgs effektivitet ved at kalde det ved hjælp af et synonym eller hardkodning af server.database.schema.object bør være det samme, fordi synonymet kun er et alternativt navn til basisobjektet. Løs den langsomme ydeevne fra basisobjektet.
 
 
 Men tag ikke mit ord for det. Du bør selv tjekke det med din plan for udførelse af forespørgsler og den faktiske ydeevne.
 Konklusion
 
 Alt i alt dækkede vi temmelig meget information om SQL Server-synonymer, så lad os opsummere.
 
 For det første er et synonym simpelthen et alternativt navn, der vil spare dig for ændringer og overførsler af objektnavne. For det andet er gode kandidater til synonymer tabeller, visninger, lagrede procedurer og funktioner. Dernæst kan du udføre kommandoer, der passer til dets basisobjekt fra et synonym. Du kan også sikre det. Så, hvis du har brug for at se listen over synonymer, har du sys.synonymer at hjælpe dig. Endelig burde ydeevnen ikke være et stort problem, hvis der ikke er nogen ydeevneproblemer med basisobjektet.
 
 Så hvorfor ikke prøve det i dag?
 
 Hvad synes du? Fortæl os det i kommentarerne.