Лучшая практика между этими двумя запросами

Question

Вчера я был на собрании группы пользователей, и они отметили, что использование параметризованных запросов лучше, чем хардкодирование запроса. Это заставило меня задуматься, делает ли это что-нибудь полезное (очевидно, в гораздо большем масштабе, чем это):

DECLARE @Client1 UNIQUEIDENTIFIER,
@Client2 UNIQUEIDENTIFIER
SET @ClientId1 ='41234532-2342-3456-3456-123434543212';
SET @ClientId2 = '12323454-3432-3234-5334-265456787654';

SELECT ClientName
FROM dbo.tblclient
WHERE id IN (@Client1,@Client2)

В отличие от:

SELECT ClientName
FROM dbo.tblclient
WHERE id IN ('41234532-2342-3456-3456-123434543212','12323454-3432-3234-5334-265456787654')

Answer 1

Параметризованные запросы и предложение IN фактически не реализуются вместе, если ваш список IN время от времени изменяется.

Прочтите этот вопрос и ответы: Параметризация предложения SQL IN

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

С точки зрения производительности, у вас будет лучшая производительность для параметризованных запросов, особенно если один и тот же запрос выполняется неоднократно, но с различными значениями параметров. Однако, если у вас есть динамический список IN (иногда 2 элемента, иногда 3), вы можете не воспользоваться преимуществом параметризованных запросов.

Впрочем, не теряй надежды. Некоторые люди смогли реализовать это (параметризованные запросы и предложение IN). Это, опять же, не тривиально.

Answer 2

В огромных базах данных и сложных запросах со многими объединениями база данных может использовать время для построения плана выполнения.При использовании параметризованных запросов план выполнения остается в кеше базы данных в течение некоторого времени при многократном вызове запроса с различными параметрами

Answer 3

Это не должно повредить, но вы получите максимальный эффект от подготовленных операторов, когда будете использовать запросы, генерируемые пользовательским вводом.Если они нажимают кнопку, чтобы «показать все», это не имеет большого значения;однако, если вы предлагаете пользователю ввести его имя, вам необходимо настроить параметры ввода перед вставкой / обновлением / выбором / и т.д.

Например, если я ввел свое имя как «Mike DROP TABLEМАСТЕР);"или какое-либо большое имя таблицы в вашей БД, это может быть очень уродливо для вас.Лучше безопасно, чем потом сожалеть, верно?

РЕДАКТИРОВАТЬ: OP прокомментировал здесь и задал вопрос.Обновлено с примером кода.

public int myNum; 
SqlParameter spNum=new SqlParameter("@myNum", SqlDbType.Int); 
//you can also check for null here (but not really relevant in this case)
command.Parameters.Add(spNum); 
string sql="INSERT INTO Table(myNum)";
sql+=" VALUES(@myNum)";
command.CommandText = sql;
int resultsCt = command.ExecuteNonQuery();

Посмотрите, как код заставляет входные данные быть целыми числами ДО того, как он будет работать с базой данных?Таким образом, если кто-то попробует какие-либо махинации, он будет отклонен до того, как сможет причинить вред БД.