Интеграционные сервисы и идентификационные столбцы

Question

Я немного новичок в SSIS, и хотя вся система кажется простой, я концептуально не понимаю процесс, который мне нужно пройти в этом сценарии:

1. Необходимо отобразить таблицы Invoice и InvoiceLine из исходной базы данных в две эквивалентные таблицы в целевой базе данных - с разными значениями идентификаторов.

2. Для каждого накладного, вставленного поперек, мне нужно получить идентификатор, которому он был присвоен, а затем вставить все его строки, ссылающиеся на этот новый идентификатор

3. На счетах имеется суррогатный ключ (номер счета), однако они могут также конфликтовать с номерами счетов в целевой системе, поэтому их также необходимо перенумеровать.

Это должен быть распространенный сценарий интеграции - есть ли общее решение?

Answer 1

Крис К.Л. - вы правы, что это сложнее, чем можно было ожидать. Для этого у меня есть три метода, которые работают в разных ситуациях:

1. Если загружаемые вами данные небольшие (сотни или тысячи, но не сотни тысяч), то вы можете сделать это: использовать команду OLEDB, которая выполняет одну вставку для каждой родительской строки и возвращает значение идентификатора обратно; затем вниз по течению присоедините выходные данные этого к дочерним строкам и вставьте их. Преимущество: интуитивно понятное. Недостаток: плохо масштабируется. Этот метод задокументирован в Интернете и должен Google для вас.

2. Если мы говорим о более крупной системе, в которой вам нужна массовая загрузка, то есть два других варианта:

а. Если у вас есть эксклюзивный доступ к таблице во время загрузки (действительно исключительный, принудительно каким-то образом), то вы можете получить максимальный существующий идентификатор из таблицы, использовать задачу скрипта служб SSIS для нумерации строк, начинающихся выше этого максимального идентификатора, а затем установить идентификацию. Вставьте, вставьте их и установите Идентификационную вставку выкл. Затем у вас есть эти сгенерированные скриптом ключи в SSIS для назначения дочерним строкам. Преимущество: быстро и просто, одна поездка в БД. Недостаток: возможные ошибки, если какой-то другой процесс одновременно вставляется в вашу таблицу. Хрупкое.

б. Если у вас нет монопольного доступа, то единственный известный мне способ - это обратная поездка в БД, поэтому: вставьте все родительские строки, но отследите ключ для них, который не является столбцом идентификации (бизнес-ключ, например). Во втором потоке данных обработайте дочерние записи, используя преобразование «Уточняющий запрос», которое использует бизнес-ключ для извлечения родительского идентификатора. Убедитесь, что поиск настроен соответствующим образом, а не кеширование, и что ваш бизнес-ключ проиндексирован.

Answer 2

Ладно, это хорошие новости / плохие новости, я боюсь. Сначала хорошие новости и немного предыстории, которую вы, возможно, знаете, но я опущу ее, если вы этого не сделаете.

Вы обычно не можете вставить что-либо в столбцы IDENTITY. Конечно, как и все в жизни, бывают моменты, когда это необходимо, и это можно сделать с помощью параметра IDENTITY_INSERT.

SET IDENTITY_INSERT MyTable ON

INSERT INTO MyTable (
       MyIdCol,
       Etc…
       ) 
SELECT SourceIdCol,
       Etc…
  FROM MySourceTable

    SET IDENTITY_INSERT MyTable OFF

Теперь вы говорите, что у вас есть суррогатные ключи в цели, но затем вы говорите, что они могут конфликтовать. Так что я немного запутался ... Используете ли вы ключи из источника (например, столбцы IDENTITY) или генерируете новые ключи в цели? Я настоятельно рекомендую не пытаться объединить пространства ключей в одном столбце ключей. Если вам нужно сохранить ключи, я бы предложил многопольный ключ, использующий что-то вроде SourceSystemId, чтобы они оставались уникальными.

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