Как архивировать связанные данные (в разных таблицах) с помощью SSIS

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

Мне нужно придумать эффективное и простое в обслуживании решение в SSIS. Я могу придумать как минимум три способа сделать это:

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

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

Я ищу оптимальный подход, у кого-нибудь есть другой подход? Как другие люди достигли бы этого?


database archive data-warehouse ssis
person Mr Shoubs    schedule 01.03.2011    source источник

Ответы (3)


arrow_upward
6
arrow_downward

Похоже, вам нужно два процесса: один для архивации старых данных и один для перезагрузки архивных данных. Я бы занялся обоими с помощью следующей методологии.

Для архивации данных:

  • Во-первых, пройдите и, используя свои бизнес-правила, определите данные, которые необходимо заархивировать. По большому счету это означает создание временной таблицы (или набора данных), содержащей только ключи данных, подлежащих архивированию. Используя в качестве примера счета-фактуры, я бы собирал только идентификаторы счетов-фактур, которые должны быть заархивированы, и этого должно быть достаточно для идентификации всех связанных дочерних данных (элементы строк счета-фактуры, информация о доставке и оплате и т. д. и т. д.). Вам может понадобиться несколько таких наборов, например, для архивирования счетов, клиентов и продавцов, поскольку ни один из них не «полностью содержится» в другом.
  • Убедитесь, что эти наборы целые и полные (то есть, они не содержат нарушенных отношений родитель/потомок). Основа всей последующей работы на этих наборах данных гарантирует, что ничего лишнего случайно не «проскользнет».
  • Затем просмотрите и скопируйте данные, указанные в этих наборах, из исходной базы данных в архивную базу данных.
  • Когда все данные будут правильно скопированы (и только тогда), вернитесь и удалите эти данные из исходных таблиц.

Для перезагрузки данных это будет почти тот же процесс, но работа с архивным набором в «живой» набор. Особые соображения включают:

  • Если перезагрузить, можно ли изменить данные? Если это так, то вам, вероятно, потребуется удалить его из архива, поскольку, когда он в конечном итоге будет повторно заархивирован, он может быть изменен. Это, или вам придется разрешить архивирование одного и того же набора данных дважды!
  • Вы, вероятно, захотите как-то пометить перезагруженные данные, чтобы они не были немедленно повторно заархивированы при следующем запуске архива.

Эта методология будет работать независимо от инструмента — SSIS или другого.

person Philip Kelley    schedule 15.03.2011
comment
Я бы добавил, что вместо перезагрузки вы можете рассматривать представления, содержащие старые и новые данные, через запрос на объединение всех для создания отчетов. - person HLGEM; 15.03.2011
comment
Интересный. Я рассматривал промежуточные таблицы, хотя в этом случае я не вижу преимущества - я могу скопировать данные непосредственно в архивную таблицу с отметкой времени (отметка времени = процесс запущен), а затем, когда закончите, пойти и удалить идентификаторы, которые были отмечены отметкой времени в время начала процесса. Как только я определил идентификатор задания, я знаю и остальные данные, которые также необходимо заархивировать. Это в значительной степени один из методов, которые я предложил в своем вопросе - +1 за подробности, но я действительно ищу оптимальное предложение метода. - person Mr Shoubs; 15.03.2011
comment
Я не могу использовать представления в POSTGRES - он не очень хорошо поддерживает кросс-запросы к БД, не говоря уже о кросс-серверных запросах :( - person Mr Shoubs; 21.03.2011

arrow_upward
0
arrow_downward

Не могли бы вы быть более конкретными?

Вам нужны «старые» данные, которые все еще присутствуют в вашей текущей базе данных? Если да - то можно просто:

  1. Резервное копирование и восстановление
  2. Спишите одно с «эффективного» удаления
  3. Создайте новый пакет служб SSIS, который будет поддерживать заполнение/обслуживание данных в будущем.

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

если это поможет отметьте как ответ

person sabyasm    schedule 01.03.2011
comment
Я хочу переместить старые данные в отдельную базу данных, а затем удалить их из исходной базы данных (выполняется ежедневно). Мне не нужны новые данные в этом архиве - они часто меняются и к ним обращаются. Некоторые из заархивированных данных, возможно, потребуется вернуть обратно, если это необходимо, и, возможно, о них будет сообщено. Извините, ваш ответ не помогает. - person Mr Shoubs; 02.03.2011

arrow_upward
0
arrow_downward

Используйте CQRS. Проблема в термине "связанные данные". Если вы разделите свои чтения (все возможные чтения в собственной базе данных/таблицах), вам не понадобятся связанные данные, и вы сможете применять правила к каждому «Агрегату» отдельно, если это необходимо. Допустим, для представлений списка вы получаете счет из двух разных источников (фактические и архивные данные) при рендеринге пейджера. Для подробного просмотра вы по-прежнему можете иметь UUID для каждого ресурса, но в этом случае приложение будет считывать из разных хранилищ данных. Ключевым моментом здесь является то, что вы избавляетесь от всех видов соединений.

person Aram    schedule 29.02.2016