Возможный вернуть идентификаторы PrimaryKey после SQL BulkCopy?
Я использую C# и использую SqlBulkCopy. У меня есть проблема все же. Я должен сделать массовую вставку в одну таблицу затем другая массовая вставка в другую таблицу.
Эти 2 имеют отношения PK/FK.
Table A
Field1 -PK auto incrementing (easy to do SqlBulkCopy as straight forward)
Table B
Field1 -PK/FK - This field makes the relationship and is also the PK of this table. It is not auto incrementing and needs to have the same id as to the row in Table A.
Таким образом, эти таблицы имеют связь "один к одному", но я не уверен, как возвратить весь их идентификатор PK, который сделала массовая вставка, так как мне нужны они для Таблицы B.
Править
Я мог сделать что-то вроде этого?
SELECT *
FROM Product
WHERE NOT EXISTS (SELECT * FROM ProductReview WHERE Product.ProductId = ProductReview.ProductId AND Product.Qty = NULL AND Product.ProductName != 'Ipad')
Это должно найти все строки, которые, где просто вставлено с sql выполняют массовое копирование. Я не уверен, как взять результаты этого, затем делают массовую вставку с ними от SP.
Единственная проблема I видит с этим, то, что, если пользователь делает, записи по одному и этот оператор работают одновременно, это могло бы попытаться вставить строку дважды в "Таблицу Обзора продукции".
Поэтому скажите, что я добрался как один пользователь, использующий ручной путь и другого пользователя, делающего массовый путь приблизительно в то же время.
ручной путь. 1. Пользователь отправляет данные 2. Linq к sql объекту продукта сделан и заполнен данными и отправлен. 3. этот объект теперь содержит ProductId 4. Другой linq к объекту sql сделан для таблицы Обзора продукции и вставляется (Идентификатор продукта от шага 3 отправляется вперед).
Массовый путь. 1. Пользователь захватывает данные от пользователя, совместно использующего данные. 2. Все строки продукта от пользователя совместного использования захватываются. 3. Массовое копирование SQL вставляет на строках продукта, происходит. 4. Мой SP выбирает все строки, которые только существуют в Таблице product, и удовлетворяет некоторым другим условиям 5. Массовая вставка происходит с теми строками.
Таким образом, что происходит, если шаг 3 (ручной путь) происходит в то же время, что и шаг 4 (массовый путь). Я думаю, что это попыталось бы вставить ту же строку, дважды вызывающую основное ограничение execption.
2 ответа
В этом сценарии я бы использовал SqlBulkCopy для вставки в staging таблицу (т.е. ту, которая похожа на данные, которые я хочу импортировать, но не является частью основных транзакционных таблиц), а затем в DB в INSERT/SELECT для перемещения данных в первую реальную таблицу.
Теперь у меня есть два варианта в зависимости от версии сервера; я могу сделать второй INSERT/SELECT во вторую реальную таблицу, или я могу использовать INSERT/OUTPUT для второй вставки, используя идентичные строки из таблицы.
For example:
-- dummy schema
CREATE TABLE TMP (data varchar(max))
CREATE TABLE [Table1] (id int not null identity(1,1), data varchar(max))
CREATE TABLE [Table2] (id int not null identity(1,1), id1 int not null, data varchar(max))
-- imagine this is the SqlBulkCopy
INSERT TMP VALUES('abc')
INSERT TMP VALUES('def')
INSERT TMP VALUES('ghi')
-- now push into the real tables
INSERT [Table1]
OUTPUT INSERTED.id, INSERTED.data INTO [Table2](id1,data)
SELECT data FROM TMP
В зависимости от ваших потребностей и степени контроля над таблицами вы можете рассмотреть возможность использования UNIQUEIDENTIFIERs (Guids) вместо ваших первичных ключей IDENTITY. Это перемещает управление ключами за пределы базы данных в ваше приложение. У этого подхода есть серьезные недостатки, поэтому он может не соответствовать вашим потребностям. Но, возможно, стоит подумать. Если вы точно знаете, что будете закачивать много данных в свои таблицы с помощью массовой вставки, часто бывает действительно удобно управлять этими ключами в вашей объектной модели, а не в приложении, полагающемся на базу данных, чтобы вернуть вам данные.
Вы также можете использовать гибридный подход с промежуточными таблицами, как предлагалось ранее. Получите данные в эти таблицы, используя идентификаторы GUID для отношений, а затем с помощью операторов SQL вы можете получить целочисленные внешние ключи по порядку и перекачивать данные в свои производственные таблицы.