Что польза альтернативна к увольнению хранимой процедуры 368 времена для обновления базы данных?

Если вы используете SQL 2008, вы можете использовать возвращающий табличное значение параметр , чтобы протолкнуть все обновления за один вызов s'proc.

обновление Между прочим, мы используем это в сочетании с оператором merge . Таким образом, sql server позаботится о том, чтобы определить, вставляем ли мы новые записи или обновляем существующие. Этот механизм используется в нескольких основных местах нашего веб-приложения и обрабатывает сотни изменений одновременно. Во время регулярной загрузки мы увидим, что этот процесс вызывается примерно 50 раз в секунду, и это НАМНОГО быстрее, чем любой другой способ, который мы нашли ... и, безусловно, НАМНОГО дешевле, чем покупка более крупных серверов БД.

Вы можете отправить полный набор данные как входные XML-данные для хранимой процедуры. Затем вы можете выполнить операции Set для изменения базы данных. На основе набора будет превосходить RBAR по производительности почти каждый раз.

Если вы используете версию SQL Server до 2008, вы можете полностью переместить свой код в саму хранимую процедуру.

В этом есть как хорошее, так и плохое.
Хорошо

• Нет необходимости передавать данные по сети.
• Быстрее, если ваша логика настроена на основе
• Увеличивается

Плохо

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

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

ОБНОВЛЕНИЕ
Бен спросил, что я имел в виду в одном из моих комментариев о CLR и SQL Server. Прочтите Использование интеграции CLR в SQL Server 2005 . Основная идея состоит в том, что вы можете написать код .Net для манипулирования данными и сохранить этот код внутри самого SQL-сервера. Это избавляет вас от необходимости читать все данные в сети и таким образом отправлять обновления обратно.

Код вызывается вашими существующими процедурами и дает вам всю мощь .net, так что вам не нужно делать что-то вроде курсоров. Sql останется установленным, в то время как код .net может выполнять операции с отдельными записями.

Между прочим, именно так были реализованы такие вещи, как heirarchyid, в SQL 2008.

Единственным реальным недостатком является то, что некоторые администраторы баз данных не любят вводить подобный код разработчика в сервер базы данных. Так что в зависимости от вашей среды это может быть не вариант.Однако, если это так, то это очень эффективный способ решить вашу проблему, оставив данные и обработку на сервере базы данных.

Можете ли вы создать пакетный оператор с 368 вызовами вашего proc, тогда по крайней мере у вас не будет 368 обходов. т.е. псевдокод

var lotsOfCommands = "spUpdateOrderDetailDiscountedItem 1; spUpdateOrderDetailDiscountedItem 2;spUpdateOrderDetailDiscountedItem ... 368'

var new sqlcommand(lotsOfCommands)
command.CommandType = CommandType.Text;

//execute command

У меня были проблемы при попытке сделать то же самое (через вставки, обновления и т. Д.). При использовании OleDbCommand с параметрами требовалось много времени, чтобы постоянно воссоздавать объект и параметры каждый раз, когда я его вызывал. Итак, я создал свойство для своего объекта для обработки такого вызова, а также добавил соответствующие «параметры» к функции. Затем, когда мне нужно было действительно вызвать / выполнить его, я перебирал каждый параметр в объекте, устанавливал его на то, что мне было нужно, а затем выполнял его. Это создало ЗНАЧИТЕЛЬНОЕ улучшение производительности ... Такой псевдокод моей операции:

protected OleDbCommand oSQLInsert = new OleDbCommand();
// the "?" are place-holders for parameters... can be named parameters, 
// just for visual purposes 
oSQLInsert.CommandText = "insert into MyTable ( fld1, fld2, fld3 ) values ( ?, ?, ? )";
// Now, add the parameters
OleDbParameter NewParm = new OleDbParameter("parmFld1", 0);
oSQLInsert.Parameters.Add( NewParm );

NewParm = new OleDbParameter("parmFld2", "something" );
oSQLInsert.Parameters.Add( NewParm );

NewParm = new OleDbParameter("parmFld3", 0);
oSQLInsert.Parameters.Add( NewParm );

Теперь команда SQL и заполнители для вызова готовы к работе ... Затем, когда я буду готов выполнить вызов это, я бы сделал что-то вроде ..

oSQLInsert.Parameters[0].Value = 123;
oSQLInsert.Parameters[1].Value = "New Value";
oSQLInsert.Parameters[2].Value = 3;

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

удачи.

Это одноразовое действие (например, «просто импортируйте эти 368 новых клиентов один раз») или вам необходимо регулярно выполнять 368 вызовов sproc?

Если это разовое действие, просто сделайте 368 звонков.
(если sproc делает гораздо больше, чем просто обновляет, и, вероятно, снижает производительность, запускайте его вечером или ночью или всякий раз, когда никто не работает).

IMO, преждевременная оптимизация вызовов базы данных для одноразовых действий не стоит того времени, которое вы тратите на нее.

Массовый импорт CSV

(1) Создайте вывод данных с помощью построителя строк как CSV, затем выполните массовый импорт CSV:

http://msdn.microsoft.com/en-us /library/ms188365.aspx

Параметры с табличными значениями были бы лучше, но поскольку вы работаете на SQL 05, вы можете использовать класс SqlBulkCopy для вставки партий записей. По моему опыту, это очень быстро.