Nie chciałbym mieć 200 przepływów danych w jednym pakiecie. Czas potrzebny na otwarcie i sprawdzenie sprawiłby, że zestarzejesz się przed czasem.
EzAPI jest fajny, ale jeśli dopiero zaczynasz przygodę z .NET i SSIS, och, cholera nie, nie chcesz tego. Myślę, że poświęcisz znacznie więcej czasu na naukę modelu obiektowego SSIS i być może zajmowanie się COM, niż wykonywanie pracy.
Ponieważ jestem leniwy, podłączę BIML jako bezpłatną opcję, której nie wymieniłeś. Z odpowiedzi na SO /programming/13809491/generating-several-similar-ssis-packages-file-data-source-to-db/13809604#13809604
- Biml to ciekawa bestia. Varigence chętnie sprzeda licencję Mist, ale nie jest to konieczne. Wszystko czego potrzebujesz to BIDSHelper, a następnie przejrzyj BimlScript i poszukaj przepisu, który zaspokoi Twoje potrzeby. Gdy to zrobisz, kliknij przycisk menu kontekstowego w BIDSHelper i whoosh, generuje pakiety.
Myślę, że to może być również podejście dla ciebie. Zdefiniujesz BIML, który opisuje, jak powinny zachowywać się twoje pakiety, a następnie je wygenerujesz. W scenariuszu opisujesz, gdzie dokonujesz zmiany i musisz naprawić N pakietów, nie, naprawisz definicję problemu i ponownie wygenerujesz pakiety.
Lub jeśli masz wystarczającą znajomość frameworka, użyj czegoś takiego jak EzAPI, aby naprawić wszystkie zepsute rzeczy. Heck, ponieważ oznaczyłeś to jako 2005, możesz również wypróbować PacMan, jeśli potrzebujesz masowych modyfikacji istniejących pakietów.
Zagadnienia dotyczące projektowania SSIS
Mówiąc ogólnie, staram się, aby moje paczki koncentrowały się na rozwiązaniu jednego zadania (załadowanie danych sprzedaży). Jeśli to wymaga 2 przepływów danych, niech tak będzie. Nienawidzę dziedziczenia to pakiet kreatora importu eksportu z wieloma niepowiązanymi przepływami danych w jednym pakiecie. Rozłóż je na coś, co rozwiązuje bardzo specyficzny problem. Dzięki temu przyszłe ulepszenia będą mniej ryzykowne, ponieważ zmniejszy się powierzchnia. Dodatkową korzyścią jest to, że mogę pracować nad ładowaniem, DimProductspodczas gdy mój stwór zajmuje się ładowaniem SnowflakeFromHellpaczki.
Następnie użyj pakietów głównych, aby zorganizować potomne przepływy pracy. Wiem, że masz rok 2005, ale wersja SSIS programu SQL Server 2012 to piżama dla kota. Uwielbiam model wdrażania projektu i ścisłą integrację między pakietami.
TSQL vs SSIS (moja historia)
Jeśli chodzi o podejście oparte wyłącznie na TSQL, w poprzednim zadaniu wykorzystali 73-krokowe zadanie do replikacji wszystkich swoich danych Informix na SQL Server. Zwykle trwało to około 9 godzin, ale mogło rozciągnąć się do około 12 godzin. Po zakupie nowej sieci SAN zmniejszyła się ona do około 7+ godzin. Ten sam logiczny proces, przepisany w SSIS, był konsekwentny przez 2 godziny. Zasadniczo największym czynnikiem ograniczającym ten czas była „darmowa” równoległość, którą uzyskaliśmy za pomocą SSIS. Zadanie agenta uruchamiało wszystkie te zadania szeregowo. Pakiet główny zasadniczo podzielił tabele na jednostki przetwarzania (5 równoległych zestawów serializowanych zadań „uruchom replikację tabeli 1”, tabeli 2 itp.), W których próbowałem podzielić wiadra na quasi równe jednostki pracy. Umożliwiło to szybkie zapełnienie około 60 tabel odnośników, a następnie przetwarzanie zostało spowolnione, gdy pojawiło się w polu „
Inne zalety dla mnie przy korzystaniu z SSIS to to, że dostaję „darmową” konfigurację, logowanie i dostęp do bibliotek .NET dla kwadratowych danych, które muszę uderzyć w okrągły otwór. Myślę, że łatwiej jest utrzymywać (przekazywać konserwację) pakiet SSIS niż czysto podejście TSQL ze względu na graficzną naturę bestii.
Jak zawsze przebieg może się różnić.