Использование SqlBulkInsert в производственных приложениях

Question

В настоящее время мы разрабатываем приложение, которое генерирует свыше 5-10 000 строк данных в конкретной таблице для каждого сеанса пользователя. В настоящее время мы используем текстовые команды sql для вставки каждой строки данных за раз, поэтому операция сохранения может занять до минуты. Мы играем с использованием SqlBulkInserts и увидели, что время сократилось до менее чем 500 мс. У кого-нибудь есть возражения против использования SqlBulkInserts в производственном приложении, где многие пользователи будут использовать систему?

Answer 1

У меня никогда не было проблем с SqlBulkCopy с установленным параметром tableLock и другим пользователем, заблокированным из-за этого. Опция TableLock повышает эффективность вставки по сравнению с тем, о чем говорили многие люди, и простое ее использование показало мне.

Мой типичный метод:

public void Bulk(String connectionString, DataTable data, String destinationTable)
{
    using (SqlConnection connection = new SqlConnection(connectionString))
    {
        using (SqlBulkCopy bulkCopy =
            new SqlBulkCopy
            (
            connection,
            SqlBulkCopyOptions.TableLock |
            SqlBulkCopyOptions.FireTriggers |
            SqlBulkCopyOptions.UseInternalTransaction,
            null
            ))
        {
            bulkCopy.BatchSize = data.Rows.Count;
            bulkCopy.DestinationTableName = String.Format("[{0}]", destinationTable);
            connection.Open();
            bulkCopy.WriteToServer(data);
        }
    }
}

Answer 2

Перед реализацией использования SqlBulkInsert попробуйте создать запрос INSERT динамически, чтобы он выглядел следующим образом:

insert into MyTable (Column1, Column2)
select 123, 'abc'
union all
select 124, 'def'
union all
select 125, 'yyy'
union all
select 126, 'zzz'

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

Answer 3

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