SQL Server 同义词和动态表名的并发安全性

Question

我正在使用一些商业模式，它们有一组相似的表，它们仅在语言名称上有所不同，例如：

Products_en
Products_fr
Products_de

我还有几个存储过程，我用来访问这些存储过程以执行一些管理功能，我选择使用同义词，因为代码很多，而且将所有内容都写成动态 SQL 很痛苦：

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'

我的问题是 SQL Server 在并发访问时如何处理同义词？我担心一个程序可能会启动，然后第二个程序会出现并更改同义词指向的表，从而导致重大问题。我可以将所有内容包装在 BEGIN TRAN 和 COMMIT TRAN 中，理论上这应该消除两个进程更改同义词的风险，但是关于这件事的文档很少，我无法得到明确的答案。

请注意，虽然这个系统是并发的，但它的流量并不高，因此使用同义词/事务的性能损失在这里并不是真正的问题。

感谢您的任何建议。

Answer 1

你的担心是正确的。同义词不打算以这种方式使用。包装它是一个事务（不确定需要什么隔离级别）可能会解决问题，但只能通过使系统成为单个用户。

如果我正在处理这个问题，那么我可能会使用动态 SQL，因为我熟悉它。但是，考虑到这一点，我想知道模式是否可以解决您的问题。
如果您为每种语言创建了架构，然后在每个架构中都有一个名为 products 的表。然后，您的存储过程可以引用非限定表名，SQL 应解析对当前用户默认模式中的表的引用。然后，您需要更改您的应用程序验证的帐户以确定它使用哪个架构，或者在存储过程中使用 EXECUTE AS 来确定哪个架构是默认的。
我还没有测试过这个模式的想法，我可能没有想到所有的事情，而且我对你的应用程序了解得不够多，不知道它在你的情况下是否真的可行。如果您决定尝试，请告诉我们。