Microsoft SQL Server Создать синоним для конкретного сеанса

Я работаю над базой данных, в которой хранятся определенные данные сеанса в отдельных таблицах для каждого сеанса. например У меня была бы таблица с именем ProductsABCD, в которой хранятся продукты, видимые для этого сеанса, где ABCD — идентификатор сеанса. Не изящно, но то, с чем мне приходится работать. В настоящее время я бы получил доступ к этим данным в формате:

DECLARE @Session AS VARCHAR(MAX) = 'ABCD'
DECLARE @strSQL AS VARCHAR(MAX)

SET @strSQL = 'SELECT * FROM Products' + @Session
EXEC (@strSQL)

Очень упрощенная версия, но любой, кто когда-либо использовал Dynamic SQL, скажет вам, как быстро это становится очень уродливым. В настоящее время я изучаю вариант использования синонимов. Я могу настроить их в динамическом SQL, а затем получить доступ к синониму без динамического. например

DECLARE @Session AS VARCHAR(MAX) = 'ABCD'
DECLARE @strSQL AS VARCHAR(MAX)

SET @strSQL = 'CREATE SYNONYM myProducts FOR Products' + @Session
EXEC (@strSQL)

SELECT  * 
FROM    myProducts

DROP SYNONYM myProducts

Хотя это работает, когда тестирует только один пользователь, это нежизнеспособный вариант, когда несколько пользователей находятся в сети, поскольку синоним доступен глобально. Кто-нибудь знает способ создать синоним, доступный только для одного сеанса за раз? Подобно тому, как временная таблица может быть доступна только для одного сеанса.

Большое спасибо.

Дополнительная информация:

Обстоятельства здесь таковы, что здесь действует некоторая бизнес-логика, которая определяет, какие продукты видны, какие цены отображаются, какие уровни запасов доступны и т. д. Каждый из них хранится в глобальных таблицах, создаваемых при запуске сеанса, а затем очищается. либо в сеансе, либо по таймеру.

Их нельзя хранить во временных таблицах, потому что время жизни истекает, когда завершается хранимая процедура установки. Невозможно хранить в одной таблице с параметром сеанса в качестве поля из-за большого количества сеансов/количества данных, доступных в системе. Это было разработано до того, как разделение стало действительно возможным. Также потребуется серьезная переработка хранимых процедур — помните, что это унаследованная существующая система.

Сеанс db здесь — это сеанс IIS, который открывает одно соединение с базой данных и удерживает этот сеанс открытым. Затем это очищается с помощью сеанса удаления, отправленного при выходе из системы, или с помощью таймера, который очищает все старые сеансы, которые не были удалены должным образом.

Я бы искал синоним, который уникален либо на период соединения, либо только на время конкретного вызова хранимой процедуры. Любой из них будет работать, если синоним недоступен для другого сеанса или хранимой процедуры.


person Matthew Baker    schedule 14.11.2017    source источник
comment
Довольно неясная концепция проблемы и решения. При чем тут сеанс? Почему сеанс имеет собственные глобальные постоянные объекты? Что делать, если сеанс прерывается или кто-то запускает несколько сеансов одновременно?   -  person Ivan Starostin    schedule 14.11.2017
comment
@IvanStarostin Добавил больше деталей к основному вопросу - надеюсь, это прояснит ситуацию. Пакет, над которым я работаю, уникален, чтобы быть вежливым!   -  person Matthew Baker    schedule 14.11.2017
comment
Запускаются ли разные сеансы под одним и тем же логином (принципом БД)?   -  person Ivan Starostin    schedule 14.11.2017
comment
То же имя пользователя, но отдельные соединения для каждого запроса. Так, например, я бы открыл соединение, настроил данные сеанса и закрыл соединение. Затем для чтения мы открывали новое соединение, считывали данные сеанса и закрывали соединение и т. д. и т. д. Мы не держим ни одного соединения открытым.   -  person Matthew Baker    schedule 15.11.2017


Ответы (1)


Возможный способ обойти этот квест - создать пользователя для сеанса, поместить все таблицы в схему для сеанса, сделать эту схему по умолчанию для этого пользователя, запустить все с execute as <session-user> и без указания схем перед таблицами. Мог бы сделать вещь - сохранить таблицы с тем же именем (но в разных схемах). Но в этом случае лучше использовать схему dbo. И, возможно, когда-нибудь попытаюсь переосмыслить все решение.

person Ivan Starostin    schedule 15.11.2017
comment
Мне нравится эта идея, я не уверен, что она будет работать с моей текущей имплантацией, но это из-за элементов вне базы данных, а не из-за самого подхода. Я собираюсь попробовать и посмотреть, как это идет. - person Matthew Baker; 15.11.2017
comment
Я изучил это и столкнулся с проблемой. Когда select вызывается внутри процедуры, приоритетом для местоположения является схема sys, собственная схема процедур, схема базы данных по умолчанию. Схема пользователя по умолчанию не рассматривается. Схема «Пользователи» вступает в игру только в том случае, если вы используете динамический SQL, и отказ от динамического является основной причиной этой части проекта. Любой способ обойти это будет принят с благодарностью. - person Matthew Baker; 23.11.2017