TSQL большая вставка реляционных данных, с поддержкой внешнего ключа - PullRequest
Новая
       26

TSQL большая вставка реляционных данных, с поддержкой внешнего ключа

3 голосов
/ 24 декабря 2011

Относительно простая проблема.
Table A имеет ID int PK, уникальный Name varchar(500) и cola, colb и т. Д.
Table B имеет внешний ключ для Table A.

Итак, в приложении мы генерируем записи для таблицы A и таблицы B в DataTables в памяти.

Мы будем генерировать тысячи таких записей на очень большом количестве «клиентов».".

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

Предлагаемое решение:

Я рассматривал возможность отправки XML-документа на SQL Server для открытия в виде набора строк вTableVarA, обновите TableVarA первичными ключами для уже существующих записей, затем вставьте отсутствующие записи и выведите их в TableVarNew, затем я выберу Name и первичный ключ из TableVarA union all TableVarNew.

Затем в коде введите правильные FK в TableB памяти и вставьте все эти записи, используя SqlBulkCopy.

Похоже ли это на хорошее решение?И если да, то каков наилучший способ заполнить FK в памяти для TableB, чтобы он соответствовал первичному ключу из возвращенного DataSet.

Ответы [ 2 ]

2 голосов
/ 24 декабря 2011

Похоже на план - но я думаю, что обработка Table A может быть проще (достаточно одной таблицы / переменной таблицы в памяти):

  • имеет TableVarA, который содержит все строки для Table A
  • обновить ID для всех существующих строк с их идентификатором (должно быть выполнимо в одной инструкции SQL)
  • вставьте все несуществующие строки (которые все еще имеют пустой ID) в Table A и запишите их ID

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

Как только вы обработаете Table A, как вы говорите, обновите внешние ключи Table B и массово вставьте эти строки за один раз.

Я не совсем понимаю, как Table B ссылается Table A - вы только что сказали, что у него есть FK, но вы не указали, в каком столбце он был (предполагая ID). Тогда как ваши строки из Table B ссылаются на Table A для новых строк, которые еще не вставлены и, следовательно, еще не имеют ID в Table A?

0 голосов
/ 25 декабря 2011

Это скорее комментарий, чем полный ответ, но мне не хватило места, поэтому, пожалуйста, не голосуйте за то, что он не отвечает критериям.

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

Я думаю, что нужно иметь дело с теми, у кого есть ключи в отдельности, при условии отсутствия риска, что PK будет удален.TVP эффективен, но вам нужны точные знания о том, что было обработано.Я думаю, вам нужно сначала выполнить поиск по имени, чтобы получить список существующих ПК, а затем обработать его с помощью TVP.

Для обеспечения целостности данных обрабатывайте остальные по одному с помощью хранимой процедуры, которая создает PK по мере необходимости.

Тысячи записей не страшны (миллионы есть).Большое количество «клиентов», это страшная часть.

...