Я не хотел бы иметь 200 потоков данных в одном пакете. Время, которое потребуется, чтобы просто открыть и проверить, сделает вас старым раньше времени.
EzAPI - это весело, но если вы новичок в .NET и SSIS, черт возьми, вы этого не хотите. Я думаю, что вы потратите гораздо больше времени на изучение объектной модели служб SSIS и, возможно, работы с COM, чем на самом деле выполняете работу.
Поскольку я ленивый, я подключу BIML как бесплатную опцию, которую вы не перечислили. Из ответа на SO /programming/13809491/generating-several-s Similar- ssis- packages- file- data- source- to- db/ 13809604# 13809604
- Бимл интересный зверь. Varigence с радостью продаст вам лицензию на Mist, но она не нужна. Все, что вам нужно, это BIDSHelper, а затем просмотрите BimlScript и найдите рецепт, который соответствует вашим потребностям. Как только вы это сделаете, нажмите кнопку контекстно-зависимого меню в BIDSHelper, и он создаст пакеты.
Я думаю, что это может быть подходом и для вас. Вы определяете свой BIML, который описывает, как должны вести себя ваши пакеты, а затем генерируете их. В сценарии вы описываете, где вы вносите изменения, и вам нужно исправить N пакетов, нет, вы исправляете свое определение проблемы и перегенерируете пакеты.
Или, если вы достаточно хорошо знакомы с фреймворком, используйте что-то вроде EzAPI, чтобы исправить и исправить все испорченные вещи. Черт возьми, так как вы пометили это как 2005, вы также можете попробовать PacMan, если вам нужно массово модифицировать существующие пакеты.
Особенности проектирования служб SSIS
Вообще говоря, я стараюсь сосредоточить свои пакеты на решении одной задачи (загрузить данные о продажах). Если для этого требуется 2 потока данных, пусть будет так. Ненавижу наследовать - это пакет из мастера импорта-импорта со множеством несвязанных потоков данных в одном пакете. Разложите их в нечто, что решает очень специфическую проблему. Это делает будущие улучшения менее рискованными, так как площадь поверхности уменьшается. Дополнительным преимуществом является то, что я могу работать над загрузкой, DimProductsпока мой миньон занимается загрузкой SnowflakeFromHellпакета.
Затем используйте главный пакет (ы) для организации дочерних рабочих процессов. Я знаю, что вы на 2005, но выпуск SSIS для SQL Server 2012 - это кошачья пижама. Мне нравится модель развертывания проекта и тесная интеграция между пакетами.
TSQL против SSIS (моя история)
Что касается подхода чистого TSQL, в предыдущем задании они использовали задание из 73 шагов для репликации всех своих данных Informix в SQL Server. Обычно это занимает около 9 часов, но может растянуться до 12 или около того. После того, как они купили новый SAN, он снизился до 7+ часов. Тот же самый логический процесс, переписанный в SSIS, был последовательным саб-2 часа. Безусловно, самым большим фактором сокращения времени стало «бесплатное» распараллеливание, которое мы получили с помощью SSIS. Задание агента выполняло все эти задачи последовательно. Основной пакет в основном разделил таблицы на блоки обработки (5 параллельных наборов сериализованных задач «запустить реплицируемую таблицу 1», таблицу 2 и т. Д.), Где я попытался разделить сегменты на квази равные по размеру единицы работы. Это позволило приблизительно 60 справочным таблицам поиска быстро заполниться, и затем обработка замедлилась, когда она попала в "
Еще один плюс для меня, использующего SSIS, заключается в том, что я получаю «бесплатную» конфигурацию, ведение журнала и доступ к библиотекам .NET для квадратных данных, которые мне нужно врезать в круглое отверстие. Я думаю, что легче поддерживать (передать обслуживание) пакет служб SSIS, чем чистый подход TSQL, благодаря графической природе зверя.
Как всегда, ваш пробег может отличаться.