Это эффективный запрос к серверу sql?

Question

Если я напишу sproc в этом формате, будет ли сервер sql делать это эффективно, или «сотка» sql будет выполняться на стороне сервера (.net)?

Примечание: это всего лишь приблизительное представление о том, как выглядит мой запрос, есть еще несколько предложений 'if' для построения моего запроса, который я выполняю, используя 'exec'

declare @sql nvarchar(4000)
declare @order nvarchar(4000)


set @sql = 'select id, name'
set @sql = @sql + ' ....' 

if(@sortOrder)
    set @order = 'order by name desc'

exec @sql + @order

Answer 1

Вместо создания строки SQL, почему бы просто не использовать оператор case в следующем порядке:

например. (при условии сортировки по имени и / или фамилии в таблице с полями FirstName и LastName)

order by
  case 
  when @sortExpression = 'lastname asc' then CAST(LastName as sql_variant)
  when @sortExpression = 'firstname asc' then CAST(FirstName as sql_variant)
  end asc,
  case
  when @sortExpression = 'lastname desc' then CAST(LastName as sql_variant)
  when @sortExpression = 'firstname desc' then CAST(FirstName as sql_variant)
  end desc

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

Answer 2

Самый простой, простой, самый простой и оптимизируемый способ - иметь полные операторы SQL для каждого параметра.

Answer 3

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

select
  t.* 
from 
  table as t 
order by
  case @val
    when 1 then column1
    when 2 then column2
  end

Если вы обнаружите, что упорядочение по является слишком динамичным и должно быть построено, или это проще сделать, то я бы создал табличную функцию, которая возвращает набор, а затем создал бы динамический SQL-оператор для этого:

select
  t.*
from
  xfn_Function(@arg1, @arg2) as t
order by
  t.col1, t.col2

Где, конечно, t.col1, t.col2 и т. Д., И т. Д. Динамически генерируются перед отправкой всего этого на сервер.

Answer 4

Производительность динамических запросов почти эквивалентна ткачеству на стороне сервера. если вы не можете найти другой способ избежать динамического запроса, вложите его в серверную часть.

Следование также работает, если у вас не так много «если»

if(@sortorder = 'name') select id, name from tbl order by name asc
if(@sortorder = 'id') select id, name from tbl order by id asc

Answer 5

Наиболее эффективным является получение любых необходимых данных из базы данных, а затем обработка сортировки в вашем приложении. Изменение порядка не приведет к изменению объема данных. Если пользователь меняет порядок сортировки, зачем совершать еще одну поездку в базу данных?

Answer 6

Чтобы конкретно ответить на ваш вопрос, не будет никакой разницы в производительности между динамическим оператором SQL, который формируется на вашем .Net-уровне, и точно такой же строкой SQL, которая формируется внутри proc.

Answer 7

Остальная часть запроса будет построена до порядка, т. Е.

@sql = 'SELECT id, name FROM myTable ORDER BY ' + @order

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

Чтобы ответить на ваш вопрос, да, это эффективно.

Answer 8

Да.

Он компилируется в команде "exec". Разница в скорости должна быть минимальной между этим и делать все это на стороне .NET.

В определенный момент времени он компилирует SQL в некоторый внутренний код. Это может произойти, когда .NET подталкивает или после.

Answer 9

Есть ли у вас веские основания делать это как динамический SQL?

Я сделал то, что у вас было раньше на SQL-сервере, и он отлично работает; это, вероятно, безопаснее (в зависимости от использования), чем передавать полностью сформированный SQL в процесс, который просто запускает его вслепую.

Если вы используете SQL 2k5 или 2k8, вы можете использовать nvarchar (max) для более длинных строк.