Является ли SqlBulkCopy подходом для обычных массовых вставок?

Question

Я разрабатываю онлайн-инструмент в .NET 4 для чтения потенциально больших (тысячи строк) страниц Excel в DataTable, а затем использую SqlBulkCopy.WriteToServer () для загрузки в соответствующую таблицу Sql Server 2000 (скоро будет 2008).,Он предназначен только для использования в моей компании, поэтому мне не нужно слишком беспокоиться о защите его для внешнего использования.

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

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

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

Я не могу найти много ссылок на недостатки использования SqlBulkCopy.Есть ли какие-либо проблемы безопасности или другие проблемы, о которых мне следует беспокоиться?Есть ли альтернативные подходы, которые я мог бы рассмотреть?Как и во всем, моя главная цель - заставить его работать как можно быстрее, при этом обеспечивая безопасность и «правильный» подход.

Большое спасибо.

Answer 1

Я бы сказал, что у вас все в порядке с этим выбором.Он используется для повышения производительности по сравнению со стандартными инструкциями вставки с обычной командой, не пакетный вызов.Вот почему он может отличаться от «стандартного» подхода с хранимыми процедурами.

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

Что касается запуска его более одного раза, мы используем его в производственном коде для больших действий с данными в несколькихместами, несколько раз - выигрыш в производительности перевешивает немного другой код DAL, который вы должны использовать для его получения.

Единственная потенциальная проблема - это нехватка памяти.Если вы создаете DataTable из графа объектов (что мы делаем), вы получаете вторую копию этих данных в памяти (albiet, непродолжительный).В некоторых местах мы изменили код с использования DataTable на использование пользовательского класса, который реализует IDataReader над графом объектов (я говорю «граф», обычно пара плоских списков).Это позволяет избежать давления памяти.