2017-01-25 10 views
0

У нас есть требование вставить большое количество записей (от 2 до 3 миллионов) в таблицу. Тем не менее, мы должны иметь возможность проверять и отделять недопустимые записи - первичный ключ, внешний ключ и недействительные нарушения - в отдельную таблицу ошибок для последующей ссылки. В моем исследовании объемная вставка на SQL-сервере хорошо работает для вставки, но я не могу найти лучший способ отфильтровывать плохие записи данных. Имеет ли промежуточный стол между помощью? Хотя мы могли проверять наличие нарушений в некоторых очередях по сравнению с промежуточной таблицей, мы должны загружать хорошие записи в фактическую таблицу с помощью другой вставки - либо путем выбора вставки, либо слияния - но эффективен ли этот подход? Я обеспокоен тем, что было бы сродни выполнению двух вставок.Массовая вставка с валидацией данных

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

Может ли кто-нибудь указать мне на более эффективное решение?

EDIT: Если этот подход является единственным решением, какой метод, по вашему мнению, лучше всего подходит для второй вставки? Вставляется ли ... select или MERGE? Согласуют ли они эффективность и скорость BULK INSERT? Или есть ли другая лучшая альтернатива?

Спасибо!

+0

У этого есть несколько подходов: http: //stackoverflow.com/questions/1004525/sqlbulkcopy-error-handling-continue-on-error – TheGameiswar

+0

@TheGameiswar Спасибо за ссылку. Я прошел через это, и, действительно, второй вариант - это то, что, по моему мнению, применимо в этом сценарии. Тем не менее, я не уверен, что это эффективно, поскольку мы будем делать 2x вставки - одну большую вставку из исходной в промежуточную таблицу, а затем другую из промежуточной таблицы в целевую. Я просто хотел узнать, есть ли еще возможности для оптимизации. –

+0

@ TheGameiswar отредактировал вопрос о сборе мнения о лучшем методе, чтобы сделать второй шаг. Благодаря! –

ответ

1

Лично я бы не стал рассматривать записи 2/3М как большие суммы. Если вам понадобятся данные в секундах, A Single (Non-Bulk) insert будет выполнять адекватно.

Если я нервничаю из-за качества данных src - мне нравится сначала загружать в stg-таблицу, а затем делать «Soft RI» - проверить на ПК, UQ, FK и т. Д., Используя SQL. Если я беспокоюсь о проблемах с числовыми/нечисловыми или плохими типами даты, тогда я делаю таблицу Starg VARCHAR (8000) для всех cols и использую TRY_CONVERT при чтении из таблицы.

Как только данные находятся в STG, вы можете легко фильтровать только хорошие строки и подробно сообщать о плохих строках.

+0

@ johnMcTighe Спасибо за комментарии. Я мог бы сказать, что наш SLA будет примерно 1 миллион записей в минуту. Разве было бы лучше, если бы объемная вставка? Кроме того, помимо разделения плохих записей нам также нужно будет вставить хорошие в фактическую таблицу. Итак, какой SQL-оператор вы считаете наиболее эффективным для этого шага? –

+0

Хорошо, я бы попробовал это: Insert To STG - это может быть объемная вставка, так как вы будете достаточно уверенно загружать строки ll (без PK, ограничений и т. Д.). Также таблица STG будет пустой до каждой загрузки. Затем обновите любые строки в Stg, которые недействительны по какой-либо причине. Это может быть несколько проходов. затем вставьте хорошие строки в виде простого вставки/выбора - также отчета о неудачных строках в качестве отдельного запроса. Если это работает достаточно быстро, тогда здорово! –

+0

@ john McTighe Надеюсь, это достаточно быстро! Я оставлю этот вопрос без ответа еще некоторое время, чтобы узнать, есть ли у других людей какие-то мысли. Если нет, отметьте ваш ответ. Спасибо за помощь! –