Czy programiści powinni używać SSIS, a jeśli tak, to dlaczego? [Zamknięte]

Jako programista .NET, z jakich powodów powinienem preferować pakiety SSIS od pisania kodu? Mamy mnóstwo pakietów w produkcji, w których obecnie pracuję i są koszmarem zarówno dla „pisania” (być może rysowania?), Jak i utrzymywania. Każdy pakiet wygląda jak miska wielokolorowego spaghetti ze skryptami C # i VB.NET zmieszanymi w punktach, w których rozkładają się abstrakcje. Aby dowiedzieć się, co robi każde „Wykonaj zadanie SQL” lub „Pętla Foreach”, muszę dwukrotnie kliknąć tę cholerną rzecz i przejrzeć drzewo wartości i wyrażeń dosłownych, rozrzuconych na wielu kartach.

Jestem otwarty, więc chciałbym wiedzieć, czy inni dobrzy programiści uważają, że SSIS jest bardziej produktywne niż zwykłe pisanie kodu. Jeśli uważasz, że SSIS jest bardziej wydajne, proszę powiedz mi, dlaczego.

Używam SSIS na co dzień do utrzymywania i zarządzania dużą hurtownią danych i kostką. Od dwóch lat zajmuję się w 100% Business Intelligence i hurtownią danych. Wcześniej przez 10 lat byłem programistą aplikacji .NET.

Wartością SSIS jest mechanizm przepływu pracy służący do przenoszenia danych z jednego miejsca do drugiego, z pewnymi ograniczonymi przekształceniami i rozgałęzieniami warunkowymi po drodze. Jeśli Twoje pakiety zawierają dużo skryptów, oznacza to, że Twój zespół używa SSIS do niewłaściwych zadań lub nie czuje się dobrze z SQL lub wpadł w szum. Pakiety SSIS są bardzo trudne do debugowania. Komponenty skryptów to absolutny koszmar i powinny być używane tylko do formatowania, zapętlania lub jako ostateczność.

1. Utrzymuj proste pakiety, zadania sql i zadania przepływu danych.
2. Wykonuj jak najwięcej pracy poza SSIS, najlepiej w języku SQL
3. Zachowaj zmienne w jednym globalnym zakresie
4. Przechowuj swój SQL w zmiennych lub przechowuj procedury, nigdy w linii
5. Przechowuj wartości zmiennych w magazynie konfiguracji, najlepiej w bazie danych SQL

Kilka razy próbowałem używać SSIS i zrezygnowałem z tego. IMO znacznie łatwiej jest po prostu zrobić wszystko, czego potrzebuję w języku C #. SSIS jest zbyt skomplikowane, ma zbyt wiele problemów i po prostu nie jest tego warte. Znacznie lepiej jest poświęcić więcej czasu na doskonalenie umiejętności C # niż na naukę SSIS - uzyskasz znacznie większy zwrot ze swojego szkolenia.

Również znajdowanie i utrzymywanie funkcjonalności w rozwiązaniu VS jest o wiele łatwiejsze. Testowanie jednostkowe za pomocą VS jest łatwe. Wszystko, co muszę zrobić, to sprawdzić źródło w Subversion i sprawdzić, jak zostało załadowane. Testowanie jednostkowe pakietów SSIS jest bardzo skomplikowane, delikatnie mówiąc.

Poza tym zdarzały się sytuacje, w których SSIS po cichu nie wypełniało niektórych kolumn w niektórych wierszach, po prostu pomijając je bez wywoływania wyjątków. Spędziliśmy dużo czasu na rozwiązywaniu problemów i ustalaniu, co się dzieje. Opracowanie alternatywnego rozwiązania w C # zajęło mniej niż godzinę i działa bez żadnych problemów przez dwa lata.

Moim zdaniem - SSIS jest tylko dla operacji ETL i nie powinno zawierać logiki poza tym zakresem.

Miałem niefortunne doświadczenie podczas pracy nad projektem, w którym myśleliśmy, że SSIS będzie wystarczająco dobrym rozwiązaniem do agregowania i łączenia danych z kilku źródeł. Niefortunne było to, że na początku działało świetnie, ale potem wymagania się zmieniły i (w końcu) zdaliśmy sobie sprawę, że to niewłaściwe narzędzie.

może po prostu używaliśmy go niepoprawnie, ale mieliśmy wiele trudności, jeśli kiedykolwiek zmieniliśmy nasz schemat i ostatecznie po prostu ponownie wykorzystaliśmy nasze definicje ORM z poziomu interfejsu, aby napisać niestandardowe narzędzie w C #, które to zrobi. Ponieważ mieliśmy już model danych, było to zaskakująco łatwe. oczywiście YMMV i ja w żadnym wypadku nie jestem ekspertem w dziedzinie SSIS, ale w tym jednym przypadku SSIS spowodowało wiele podwójnej pracy i bólów głowy, kiedy po prostu zakasał rękawy i „ręczne kodowanie” było łatwiejsze niż oczekiwano.

Rozważając SSIS, dużo myślałbym o elastyczności.

SSIS ma swoje miejsce, a to miejsce nie jest ogólnym programowaniem lub zamiennikiem procedur składowanych. Pochodzi ze szkoły ETL (Extract, Transform, and Load) i na tym polega jego siła.

Stara nazwa (DTS, Data Transformation Services) i nowa nazwa (SSIS, Sql Server Integration Services) wyjaśniają, że jest to usługa (lub zestaw usług) zaprojektowana do manipulowania danymi w celu integracji bazy danych SQL Server z większymi procesami.

Jeśli chcesz programowo przenieść dane, możesz przyjrzeć się Rhino ETL.

Pracuję również nad własnym frameworkiem, Fluent ETL , ponieważ uważam, że SSIS jest zbyt zaangażowane w proste zadania związane z danymi związanymi z programowaniem, takie jak ładowanie danych testów jednostkowych z pliku CSV.

SSIS nie jest programem. Wiele działań jest szybszych w SSIS, a jako administrator otrzymujesz bardzo ładne szczegółowe informacje o postępie i błędach - co może być bardzo dobre w scenariuszach, które SSIS ma rozwiązać, ponieważ czasami coś idzie nie tak, a administrator potrzebuje dużo Informacja.

Biorąc to pod uwagę, SSIS nie jest tak naprawdę użyteczne, jeśli nie masz rzeczy, które same się wyjaśniają - są przeznaczone do czegoś, zbyt wiele w programowaniu ogólnym sprawia, że ​​mają pecha.