Sqlserver
 sql >> Base de données >  >> RDS >> Sqlserver

7 faits sur les synonymes de SQL Server que vous devez savoir

Avant l'apparition des synonymes SQL Server, tout le monde souhaitait simplifier et améliorer son expérience de base de données.

Imaginez que vous ayez une application avec une base de données qui fait référence à une autre base de données du même serveur. Ensuite, une réorganisation majeure oblige votre équipe à transférer l'autre base de données vers un autre serveur.

Il ne fait aucun doute que votre application se cassera. Mais que ferez-vous dans ce cas ? Lier les 2 serveurs et coder en dur toutes les références (à nouveau) pour pointer vers le nouveau serveur ?

Vous pouvez le faire si vous le souhaitez et oublier si vous n'avez que quelques ou une douzaine de références. Mais si un autre transfert ou un changement de nom se produit, vous devrez répéter le même cauchemar.

Néanmoins, il existe une meilleure façon de gérer cela.

Présentation des synonymes SQL Server

Avant de nous plonger dans ce que vous pouvez faire avec les synonymes SQL Server, décrivons ce qu'ils sont.

Un synonyme dans n'importe quelle langue parlée et écrite fait référence à un mot ou à une phrase qui a la même signification qu'un autre mot ou une autre phrase. Donc, le mot magnifique est le synonyme de beau et attrayant .

Semblable à ce que nous savons des synonymes de mots et d'expressions, les synonymes SQL Server font référence à un nom alternatif d'un objet de base de données résidant sur un serveur local ou distant. En savoir plus ici.

Comme vous le verrez dans les faits suivants, les synonymes SQL Server peuvent rendre la maintenance de votre application beaucoup plus facile.

Alors, commençons !

1. Les synonymes SQL Server peuvent simplifier votre travail lorsque les objets de base sont transférés ou renommés

Premièrement, ils vous éviteront les problèmes de modifications de code lorsqu'une base de données est déplacée vers un autre serveur ou renommée pour une raison quelconque. Référons-nous au scénario que nous avons mentionné dans cet article d'ouverture.

Une réorganisation majeure oblige votre équipe à modifier une référence à tous les objets dans mydatabase2 dans prodserver2.mydatabase2.

Donc, vous interrogez sys.sql_modules avec toutes les occurrences de mydatabase2 de madatabase1 .

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

Maintenant, la sortie du script ci-dessus répertorie tous les objets ayant des références à mydatabase2 . Bien, hein ? Et cela aidera à définir l'étendue du travail qui doit être fait.

Mais ce n'est que le début. Vous devez également vérifier s'il existe du code dans votre application cliente ou tout autre code faisant référence à la même chose en dehors de votre base de données.

La quantité de code affectée indique l'ampleur de votre nouveau problème.

Maintenant, voici quelques informations supplémentaires sur ce qui se passe dans ce script :

  • sys.sql_modules inclure des objets SQL qui sont des modules définis par SQL comme des vues, des procédures stockées, des fonctions, etc.
  • Le nom colonne est l'endroit où se trouve le nom de l'objet.
  • Le code SQL de l'objet se trouve dans la définition colonne de sys.sql_modules .
  • sys.all_objects inclure tous les objets de votre base de données comme les tables, les vues, etc.
  • Nous avons pris le type_desc colonne pour déterminer de quel type d'objet il s'agit (vue, procédure stockée, etc.)
  • Le où la clause filtre la requête pour tout code SQL qui inclut une référence à mydatabase2 .
  • Pour obtenir un résultat satisfaisant en utilisant le script ci-dessus, vous devez avoir l'autorisation pour tous les objets. Vérifiez auprès de votre administrateur de base de données ou d'une personne ayant un rôle similaire à ce sujet. Vous pouvez également vérifier ceci.

Maintenant que vous savez comment déterminer la portée de votre travail, il est temps de le corriger.

Comment réparer ce gâchis de code pour qu'il ne se reproduise plus

Très bien. J'ai une confession à vous faire.

L'utilisation des synonymes SQL Server ne fera que réduire vos problèmes au minimum, mais ne les éliminera pas.

Maintenant qu'il est à l'écart, voici la bonne nouvelle :si vous avez 10 références à un objet distant avant d'utiliser des synonymes, vous modifiez les 10. Mais une fois que vous commencez à utiliser un synonyme pour cet objet distant, au lieu de modifier 10 occurrences, vous ne changez que 1. Rien de plus.

Maintenant, voici les étapes pour résoudre ce problème en utilisant des synonymes :

  1. Créez un synonyme pour chacun des objets distants. Ainsi, au lieu de prodserver2.mydatabase2.schema1.object1 vous pouvez vous y référer en utilisant le synonyme.
  2. Modifier les références à chaque objet en son synonyme.

Plus tard, vous découvrirez les détails de la façon de procéder.

Le plat à emporter :

Les synonymes fournissent une couche d'abstraction pour protéger les références aux objets de base de n'importe quelle partie de votre code, que ce soit dans votre base de données, votre application cliente ou ailleurs. Ainsi, vous pouvez vous réjouir lorsqu'un autre changement se produit, qu'il s'agisse d'un transfert d'objet ou d'un changement de nom.

2. Vous pouvez créer des synonymes SQL Server pour la plupart des objets

Ensuite, découvrons quels objets peuvent avoir des synonymes ?

  • Tableaux
  • Vues
  • Procédures stockées
  • Fonctions

Maintenant que vous connaissez les types d'objets, vous avez peut-être une idée de ce que vous pouvez faire avec les synonymes. Soyons plus précis.

3. Vous pouvez émettre des commandes appropriées pour le synonyme d'objet

Troisièmement, voici quelques commandes spécifiques pour chaque type d'objet.

Tableaux

Autant que vous pouvez faire un SELECT, INSERT, UPDATE et DELETE sur une table, vous pouvez faire la même chose sur son synonyme.

Donc, au lieu de :

SELECT * FROM prodserver2.mydatabase2.schema1.table1

Vous pouvez avoir une version plus courte qui résistera au prochain changement :

SELECT * FROM synonym1

Puisque c'est le cas, vous pouvez également faire ceci :

UPDATE synonym1
SET column1 = <value>

Et il en va de même pour INSERT et DELETE.

Cependant, veuillez noter les points suivants :

  • L'insertion d'un nouvel enregistrement via un synonyme ajoutera un nouvel enregistrement à la table de base. Dans notre cas, prodserver2.mydatabase2.schema1.table1 .
  • La mise à jour et la suppression auront le même effet.

Jusqu'à présent, nous n'avons montré que les commandes DML. Qu'en est-il des commandes DDL comme DROP ?

Malheureusement, vous ne pouvez pas les exécuter. En voici la raison :

La suppression d'un synonyme ne supprimera pas la table de base. Il laissera tomber le synonyme. J'entrerai dans les détails à ce sujet dans un instant.

Mais voici une autre chose que vous pouvez faire avec les synonymes de tables SQL Server :les JOIN.

À quel point cela peut-il être pratique ? Au lieu d'émettre ceci :

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

Vous pouvez effectuer ceci :

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

Est-ce plus simple ? Bien sûr !

Procédures stockées

Une commande pertinente que vous pouvez faire avec un synonyme d'une procédure stockée est EXEC.

Ainsi, au lieu d'invoquer une procédure distante comme celle-ci :

EXEC prodserver2.mydatabase2.schema1.spProcedure1

Vous pouvez créer un synonyme pour la procédure ci-dessus. Appelons-le synProcedure1 . Et invoquez-le de cette façon :

EXEC synProcedure1

Pouvons-nous continuer? Vous pouvez faire à peu près la même chose avec les VIEW et les FUNCTION. Bien sûr, si vous disposez des autorisations requises. Mais d'abord, voyons comment créer des synonymes SQL Server.

4. Vous pouvez commencer votre quête avec des synonymes SQL Server avec CREATE

Nous avons atteint le point où vous pouvez créer des synonymes. Voici comment nous pouvons le faire en utilisant T-SQL pour une table :

CREATE SYNONYM synonym1 FOR prodserver2.mydatabase2.schema1.table1

Mais prenez note de cette mise en garde :

Vérification de l'existence et de l'autorisation pour mydatabase2.schema1.table1 dans prodserver2 est différé jusqu'à l'exécution.

Cela signifie que vous ne saurez pas si :

  • les 2 serveurs (prodserver1 et prodserver2 ) sont déjà liés.
  • la base de données mydatabase2 , le schéma schema1 , et le tableau table1 existent réellement.
  • votre accès à ces ressources est autorisé.

Donc, après avoir créé le synonyme, testez-le en exécutant les commandes qui devraient fonctionner.

Et avec les procédures stockées, les vues et les fonctions, vous devez agir de la même manière.

Mais ce n'est pas tout. Si nous pouvons créer un synonyme, nous pouvons également le supprimer en utilisant :

DROP SYNONYM synonym1

Et voici une autre mise en garde :étant donné que vous pouvez supprimer des synonymes à tout moment, les références aux synonymes supprimés ne seront vérifiées qu'au moment de l'exécution.

Donc, avant de supprimer un synonyme, vérifiez sys.sql_modules car s'il y a des références à celui-ci.

Utilisation de SQL Server Management Studio (SSMS) pour créer et supprimer des synonymes

Jusqu'à présent, nous avons utilisé T-SQL pour créer et supprimer des synonymes SQL Server. Vous préférerez peut-être utiliser une interface graphique lorsque vous faites la même chose.

Lançons le bal.

Créer des synonymes

Si taper les commandes n'est pas votre truc, voici les étapes à suivre pour créer des synonymes :

  1. Exécutez SSMS et connectez-vous à votre serveur SQL.
  2. Recherchez la base de données dans laquelle vous souhaitez créer un synonyme.
  3. Développez-le.
  4. Cliquez avec le bouton droit sur Synonymes dossier et sélectionnez Nouveau synonyme .
  5. Remplissez le formulaire avec les informations requises pour les synonymes, y compris le nom, le schéma, etc.
  6. Cliquez sur OK .

Ci-dessous, une capture d'écran du formulaire dans SSMS :

Supprimer les synonymes

En parlant de préférences, taper les commandes pour créer des synonymes est mon genre de truc. Mais les déposer à volonté est plus simple que de taper les commandes. Bien sûr, c'est juste mon goût. Quoi qu'il en soit, voici les étapes à suivre lors de la suppression d'un synonyme :

  1. Exécutez SSMS et connectez-vous à votre serveur SQL.
  2. Recherchez la base de données où réside le synonyme que vous souhaitez supprimer.
  3. Développez-le.
  4. Développez les Synonymes dossier.
  5. Recherchez le synonyme que vous souhaitez supprimer.
  6. Cliquez avec le bouton droit sur le synonyme que vous souhaitez supprimer et sélectionnez Supprimer .
  7. Cliquez sur OK .

Pour résumer les étapes ci-dessus, faites simplement un clic droit sur le synonyme à supprimer, puis sélectionnez Supprimer et enfin, cliquez sur OK .

Vous trouverez ci-dessous une capture d'écran de la fenêtre qui s'affichera avant la confirmation de la suppression :

5. Vous pouvez sécuriser les synonymes SQL Server

À l'aide de GRANT, DENY ou REVOKE, vous pouvez contrôler l'accès à un synonyme.

Pour accorder une autorisation SELECT au synonyme synonym1 à un utilisateur nommé testuser , vous procédez comme suit :

GRANT SELECT ON synonym1 to testuser

Les autres autorisations que vous pouvez ajouter ou supprimer d'un synonyme sont les suivantes :

  • CONTRÔLE
  • EXÉCUTER
  • MISE À JOUR
  • INSÉRER
  • SUPPRIMER
  • AFFICHER LA DÉFINITION
  • PRENDRE PROPRIÉTÉ

6. Vous ne trouvez pas cette table, cette vue ou cette procédure ? C'est peut-être un synonyme

L'un des problèmes qu'un nouveau venu dans votre équipe peut rencontrer est une table, une vue, une procédure ou une fonction "manquante". Bien sûr, si SELECT est émis sur un objet, il peut s'agir d'une table ou d'une vue. Mais il ne peut pas le trouver dans la liste des tables ou la liste des vues. Et s'il n'a pas utilisé les synonymes SQL Server auparavant, c'est un problème supplémentaire.

Un manque d'orientation, une lacune dans la documentation ou une lacune dans vos normes peuvent être mises en ordre. Voici un script astucieux qui vous aidera à présenter la liste des synonymes et son objet de base à votre nouveau membre d'équipe :

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

Un objet "manquant" ? Plus si c'est un synonyme.

Mais avant de vous lancer dans l'exécution de ce script, voici quelques éléments supplémentaires à prendre en compte :

  • sys.synonyms est l'endroit où tous les synonymes SQL Server sont définis dans la base de données actuelle.
  • Nous avons pris les types et les descriptions de type (type et type_desc respectivement) dans sys.all_objects . Si vous avez une meilleure idée autre que de les joindre avec une sous-requête, faites-le moi savoir.
  • OBJECTPROPERTYEX est utilisé pour obtenir le type de l'objet de base s'il s'agit d'une table, d'une procédure stockée ou autre.
  • Enfin, si vous ne disposez pas des autorisations minimales requises pour exécuter ce script et obtenir le résultat souhaité, il est temps de vous lier d'amitié avec votre DBA ou une personne ayant un rôle similaire :)

Mais vous vous demandez peut-être pourquoi faire tout cela si cela ne fonctionne pas bien ?

7. Les synonymes SQL Server auront-ils un impact sur les performances ?

C'est une préoccupation commune. Et pour étoffer ce qui se passe dans les coulisses, jetons un coup d'œil au résumé de ce qui se passera dans le plan d'exécution :

  1. Lors de l'exécution du code le plus simple avec un synonyme (par exemple, SELECT * de synonyme1), SQL Server entrera dans une phase de liaison où l'objet de base remplacera le synonyme.
  2. Ensuite, quel que soit le meilleur plan d'optimisation pour exécuter une commande sur l'objet de base, ce sera le même.

Voici quelques questions et réponses concernant les 2 affirmations ci-dessus :

  1. Combien de temps SQL Server effectue-t-il la phase de liaison ? RÉPONSE :Cela ne prend pas longtemps. Cela se produit généralement en un clin d'œil.
  2. Si l'étape suivante utilise le même meilleur plan d'optimisation avec l'objet de base et que la requête vers l'objet de base est "assez rapide", sera-t-elle plus lente ? RÉPONSE :Non, car il utilisera le même plan d'exécution.
  3. Qu'en est-il de l'authentification depuis le nouveau serveur ? RÉPONSE :S'il y a de légers retards causés par le transfert d'une base de données vers un nouveau serveur, ils ne sont pas causés par le synonyme. Interrogez les performances de l'appeler à l'aide d'un synonyme ou de coder en dur le server.database.schema.object devrait être le même car le synonyme n'est qu'un nom alternatif pour l'objet de base. Résolvez les performances lentes de l'objet de base.

Mais ne me croyez pas sur parole. Vous devriez le vérifier par vous-même avec votre plan d'exécution de requête et les performances réelles.

Conclusion

Dans l'ensemble, nous avons couvert à peu près les informations sur les synonymes SQL Server, alors récapitulons.

Tout d'abord, un synonyme est simplement un nom alternatif qui vous évitera des changements de noms d'objets et des transferts. Deuxièmement, les bons candidats pour les synonymes sont les tables, les vues, les procédures stockées et les fonctions. Ensuite, vous pouvez effectuer des commandes appropriées à son objet de base à partir d'un synonyme. Vous pouvez également le sécuriser. Ensuite, si vous avez besoin de voir la liste des synonymes, vous avez sys.synonyms pour vous aider. Enfin, les performances ne devraient pas poser de problème s'il n'y a pas de problèmes de performances avec l'objet de base.

Alors pourquoi ne pas l'essayer aujourd'hui ?

Qu'en penses-tu? Faites-le nous savoir dans les commentaires.