SqlBulkCopy и DataTables с Родительским/Дочерним Отношением на Столбце Идентификационных данных

  1. Запись Ваша собственная библиотека AOP.
  2. отражение Использования для генерации регистрирующегося прокси по экземплярам (не уверенный, если можно сделать это, не изменяя некоторую часть существующего кода).
  3. Перезапись блок и вводят Ваш код входа (в основном то же как 1).
  4. Хост CLR и добавляет вход на этом уровне (я думаю, что это - самое трудное решение реализовать, не уверенный, если у Вас есть необходимые рычаги в CLR хотя).
25
задан Community 23 May 2017 в 12:09
поделиться

2 ответа

Думаю, вам придется столкнуться с компромиссом между производительностью BulkInsert и надежностью Identity.

Можете ли вы временно поместить базу данных в режим SingleUserMode. для выполнения вставки?

Я столкнулся с очень похожей проблемой в моем проекте преобразования, когда я добавляю столбец Identity в очень большие таблицы, и у них есть дочерние элементы. К счастью, мне удалось настроить идентификацию родительского и дочернего источников (я использовал TextDataReader) для выполнения BulkInsert, и я создал родительский и дочерний файлы одновременно.

Я также получил прирост производительности, о котором вы говорите , Источник OleDBDataReader -> StreamWriter ... и затем TextDataReader -> SQLBulk

0
ответ дан 28 November 2019 в 21:58
поделиться

Прежде всего: SqlBulkCopy не позволяет делать то, что вы хотите. Как следует из названия, это просто улица с односторонним движением. Я перемещаю данные на сервер sql как можно быстрее. Это версия .Net старой команды массового копирования, которая импортирует необработанные текстовые файлы в таблицы. Таким образом, нет никакого способа вернуть значения идентификаторов, если вы используете SqlBulkCopy.

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

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

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

  • Попробуйте сгенерировать идентификаторы на основе ваших данных. Если бы это было возможно, ваша проблема исчезла бы. Не говорите поститься «это невозможно». Может быть, вы можете использовать идентификаторы строк, которые можно очистить на этапе постобработки?

И еще одно замечание: увеличение коэффициента 34 при использовании BulkCopy кажется незначительным. Если вы хотите быстро вставлять данные, убедитесь, что ваша база данных настроена правильно.

В противном случае накладные расходы сети обычно становятся узким местом.

  • Попробуйте сгенерировать идентификаторы на основе ваших данных. Если бы это было возможно, ваша проблема исчезла бы. Не говорите поститься «это невозможно». Может быть, вы можете использовать идентификаторы строк, которые можно очистить на этапе постобработки?

  • И еще одно замечание: увеличение коэффициента 34 при использовании BulkCopy кажется незначительным. Если вы хотите быстро вставлять данные, убедитесь, что ваша база данных настроена правильно.

    В противном случае накладные расходы сети обычно становятся узким местом.

  • Попробуйте сгенерировать идентификаторы на основе ваших данных. Если бы это было возможно, ваша проблема исчезла бы. Не говорите поститься «это невозможно». Возможно, вы можете использовать идентификаторы строк, которые можно очистить на этапе постобработки?

  • И еще одно замечание: увеличение коэффициента 34 при использовании BulkCopy кажется незначительным. Если вы хотите быстро вставлять данные, убедитесь, что ваша база данных настроена правильно.

    Увеличение коэффициента 34 при использовании BulkCopy кажется незначительным. Если вы хотите быстро вставлять данные, убедитесь, что ваша база данных настроена правильно.

    Увеличение коэффициента 34 при использовании BulkCopy кажется незначительным. Если вы хотите быстро вставлять данные, убедитесь, что ваша база данных настроена правильно.

    9
    ответ дан 28 November 2019 в 21:58
    поделиться