Должен ли я использовать динамический SQL или есть другой способ

у меня есть что-то вроде этого:Должен ли я использовать динамический SQL или есть другой способ

AND t2.AUD_ORGID IN (SELECT Org_ID 
        FROM [development_company_database].[dbo].fx_Rights_ORGIDs(@ORG_ID))

Я работаю на базы данных A и fx_Rights_ORGIDs находится на базы данных B. Должен ли я использовать динамический SQL для подключения к нему (I не очень хочется)

Dymamic:

SET @MANDB = (SELECT DatabseDB FROM SERVER) 
SET @MANOwner = (SELECT DatabaseOwner FROM SERVER) 
SET @serverMan = (Select @DatabseDB +'.'+ @DatabaseOwner) ... 

...AND t2.AUD_ORGID IN (SELECT Org_ID FROM ['+ @COMPANYDB +'].['+ @COMPANYOwner +'].fx_Rights_ORGIDs('+ CAST(@ORG_ID AS VARCHAR) + ')) 

...EXEC sp_executesql @Tsql2

Просто интересно, есть ли способ вокруг, я не хочу жёстко базу данных, как это:

[development_company_database].[dbo].

источник

2014-02-12 TheUser

Почему вы не хотите жестко закодировать имена баз данных? Я могу видеть, как вы хотели бы избежать разбрызгивания имени базы данных с помощью кода, но использование динамического SQL для работы вокруг этого приведет к более беспорядочному (и, вероятно, более медленному) коду. Если вам понадобится заменить имя базы данных, выполните простой поиск и замените вместо этого. – SchmitzIT

@SchmitzIT: могу ли я назначить детали соединения для @variables и использовать их? что-то вроде '@ serverMan.fx_Rights_ORGIDs' – TheUser

Да, вы могли бы это сделать. Тем не менее, вам нужно будет сохранить запрос в символьном символе SQL. То есть 'SELECT @sql = 'SELECT * FROM' + @database + '.' + @owner + '.tableName''. Это усложнит процесс отладки, хотя если что-то пойдет не так. Я обычно заканчиваю 'PRINT @ sql', чтобы сгенерировать исполняемый оператор, который затем можно скопировать/вставить в новое окно для тестирования набора результатов. – SchmitzIT

Для альтернативного взгляда на вещи, я бы сказал, что есть несколько факторов, которые я бы рассмотрел здесь.

Является ли название базы данных и местоположение согласованным? Если это так, и вы единственный, кто его запускает, hardcoding переносимый скрипт не так уж плох. Однако лично, если имя базы данных меняется, я бы скорее просто изменил одну запись в верхней части скрипта и убедился, что она согласована повсюду. Альтернативой было бы использовать функциональность Template в SSMS 2012. Это по сути делает то же самое, что и Ctrl + H. Я полагаю, это зависит от того, насколько вы планируете изменить этот скрипт в будущем.
Это хранимая процедура? Если вы его много запускаете, то это, вероятно, должно быть, и если да, то жестко заданные имена базы данных не идеальны. Лучше объявлять переменные и устанавливать их во время выполнения.

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

источник

2014-02-12 12:57:24

Должен ли я использовать динамический SQL или есть другой способ

ответ

Смежные вопросы