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