Синонимы 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 в хранимом процессе, чтобы решить, какая схема является стандартной. Я не проверял эту идею схемы, возможно, я не думал обо всем, и я не знаю достаточно о вашем приложении, чтобы знать, действительно ли оно работоспособно в вашем случае. Дайте нам знать, если решите попробовать.