SQL Server Synonymes et Concurrency sécurité avec des noms de table dynamiques

Question

Je travaille avec des schémas commerciaux, qui ont aa ensemble de tables similaires, qui ne diffèrent que par le nom de la langue, par exemple:

Products_en 
Products_fr 
Products_de 

J'ai aussi plusieurs procédures stockées que je me sers pour y accéder pour exécuter certaines fonctions administratives, et je l'ai choisi d'utiliser des synonymes car il y a beaucoup de code et d'écrire tout comme SQL dynamique est juste douloureux:

declare @lang varchar(50) = 'en' 

if object_id('dbo.ProductsTable', 'sn') is not null drop synonym dbo.ProductsTable 
exec('create synonym dbo.ProductsTable for dbo.Products_' + @lang) 

/* Call the synonym table */ 
select top 10 * from dbo.ProductsTable 
update ProductsTable set a = 'b' 

Ma question est de savoir comment SQL Server traite les synonymes quand il s'agit de con accès actuel? Ma crainte est qu'une procédure puisse commencer, puis une seconde venir et changer la table que le synonyme pointe à mi-chemin en causant des problèmes majeurs. Je pourrais tout emballer dans un BEGIN TRAN et COMMIT TRAN qui devrait théoriquement enlever le risque de deux processus changeant un synonyme, cependant la documentation est rare sur cette matière et je ne peux pas obtenir une réponse définitive. Il est à noter que, bien que ce système soit concurrentiel, il ne génère pas beaucoup de trafic, ce qui fait que les performances de l'utilisation de synonymes/transactions ne sont pas vraiment un problème ici.

Merci pour vos suggestions.

Answer 1

Votre peur est correcte. Les synonymes ne sont pas destinés à être utilisés de cette manière. L'emballer est une transaction (je ne sais pas quel niveau d'isolation serait requis) pourrait résoudre le problème, mais seulement en rendant le système utilisateur unique.

Si j'avais affaire à cela, je serais probablement allé avec SQL dynamique parce que je suis familier avec elle. Cependant, après y avoir réfléchi, je me demande si les schémas pourraient résoudre votre problème.
Si vous avez créé un schéma pour chaque langue et que vous avez ensuite créé une table appelée produits dans chaque schéma. Votre proc stocké peut ensuite référencer un nom de table non qualifié et SQL doit résoudre la référence à la table qui se trouve dans le schéma par défaut de l'utilisateur actuel. Vous devrez ensuite modifier le compte sur lequel votre application s'authentifie pour déterminer le schéma utilisé ou utiliser EXECUTE AS dans un proc stocké pour décider quel schéma est par défaut.
Je n'ai pas testé cette idée de schéma, je n'ai peut-être pas pensé à tout et je ne connais pas assez votre application pour savoir si elle est réellement utilisable dans votre cas. Faites-nous savoir si vous décidez de l'essayer.