Sollten Programmierer SSIS verwenden und wenn ja, warum? [geschlossen]

Aus welchen Gründen sollte ich als .NET-Entwickler SSIS-Pakete dem Schreiben von Code vorziehen? Wir haben eine Menge Pakete in der Produktion, in denen ich gerade arbeite, und sie sind ein Albtraum, sowohl zu "schreiben" (vielleicht zu zeichnen?) Als auch zu warten. Jedes Paket sieht aus wie eine Schüssel mit mehrfarbigen Spaghetti mit C # - und VB.NET-Skripten, die an den Stellen gemischt werden, an denen die Abstraktionen zusammenbrechen. Um herauszufinden, was jede "SQL-Task ausführen" oder "Foreach-Schleife" bewirkt, muss ich auf das verdammte Ding doppelklicken und durch einen Baum von Literalwerten und Ausdrücken blättern, der auf mehrere Registerkarten verteilt ist.

Ich bin aufgeschlossen und möchte wissen, ob andere gute Entwickler SSIS produktiver finden als nur Code zu schreiben. Wenn Sie SSIS produktiver finden, sagen Sie mir bitte warum.

Ich verwende jeden Tag SSIS, um ein großes Data Warehouse und einen Cube zu warten und zu verwalten. Ich bin seit zwei Jahren zu 100% Business Intelligence und Data Warehousing. Davor war ich 10 Jahre lang .NET-Anwendungsentwickler.

Der Wert von SSIS ist eine Workflow-Engine zum Verschieben von Daten von einem Ort zum anderen mit möglicherweise eingeschränkter Transformation und bedingter Verzweigung auf dem Weg. Wenn Ihre Pakete viel Skript enthalten, verwendet Ihr Team SSIS für die falschen Aufgaben oder ist mit SQL nicht vertraut oder hat sich dem Hype verschrieben. SSIS-Pakete sind sehr schwer zu debuggen. Skriptkomponenten sind ein absoluter Albtraum und sollten nur zum Formatieren, Schleifen oder als letztes Mittel verwendet werden.

1. Halten Sie Ihre Pakete einfach, SQL-Aufgaben und Datenflussaufgaben.
2. Arbeiten Sie so viel wie möglich außerhalb von SSIS, vorzugsweise in SQL
3. Halten Sie Ihre Variablen in einem einzigen globalen Bereich
4. Behalten Sie Ihre SQL in Variablen oder Speicherprozeduren, niemals inline
5. Bewahren Sie Ihre Variablenwerte in einem Konfigurationsspeicher auf, vorzugsweise in einer SQL-Datenbank

Ich habe mehrmals versucht, SSIS zu verwenden, und es aufgegeben. IMO ist es viel einfacher, einfach alles zu tun, was ich in C # brauche. SSIS ist zu komplex, es hat zu viele Fallstricke und es lohnt sich einfach nicht. Es ist viel besser, mehr Zeit für die Verbesserung der C # -Fähigkeiten aufzuwenden als für das Erlernen von SSIS - Sie erhalten viel mehr Rendite für Ihr Training.

Auch das Finden und Aufrechterhalten von Funktionen in einer VS-Lösung ist sehr viel einfacher. Unit-Tests mit VS sind einfach. Alles, was ich tun muss, ist, die Quelle in Subversion einzuchecken und zu überprüfen, wie sie geladen wurde. Unit-Tests von SSIS-Paketen sind, gelinde gesagt, sehr aufwändig.

Außerdem gab es Situationen, in denen SSIS einige Spalten in einigen Zeilen stillschweigend nicht ausfüllte und sie nur übersprang, ohne Ausnahmen auszulösen. Wir haben viel Zeit damit verbracht, Fehler zu beheben und herauszufinden, was los ist. Die Entwicklung einer alternativen Lösung in C # dauerte weniger als eine Stunde und funktioniert zwei Jahre lang ohne Probleme.

Meiner Meinung nach ist SSIS nur für ETL-Operationen vorgesehen und sollte keine Logik außerhalb dieses Bereichs enthalten.

Ich hatte die unglückliche Erfahrung, an einem Projekt zu arbeiten, bei dem wir dachten, SSIS wäre eine ausreichend gute Lösung, um Daten aus verschiedenen Quellen zu aggregieren und zu kombinieren. Das Unglückliche war, dass es zuerst großartig funktionierte, aber dann änderten sich die Anforderungen und wir erkannten (irgendwann), dass es das falsche Werkzeug war.

Vielleicht haben wir es nur falsch verwendet, aber wir hatten große Schwierigkeiten, wenn wir jemals unser Schema geändert haben, und wir haben schließlich einfach unsere ORM-Definitionen vom Frontend wiederverwendet, um ein benutzerdefiniertes Tool in C # zu schreiben, um dies zu tun. Da wir das Datenmodell bereits hatten, war dies überraschend einfach. Natürlich sind YMMV und ich kein SSIS-Experte, aber in diesem Fall verursachte SSIS eine Menge Doppelarbeit und Kopfschmerzen, als wir nur die Ärmel hochkrempelten und die Handcodierung einfacher als erwartet durchführten.

Daher würde ich viel über Flexibilität nachdenken, wenn ich über SSIS nachdenke.

SSIS hat seinen Platz, und dieser Platz ist keine allgemeine Programmierung oder ein Ersatz für gespeicherte Prozeduren. Es kommt von der ETL-Schule (Extrahieren, Transformieren und Laden) und dort ist es am stärksten.

Der alte Name (DTS, Data Transformation Services) und der neue Name (SSIS, SQL Server Integration Services) machen deutlich, dass es sich um einen Dienst (oder eine Reihe von Diensten) handelt, mit dem Daten bearbeitet werden können, um die SQL Server-Datenbank in größere Prozesse zu integrieren.

Wenn Sie Ihre Daten programmgesteuert verschieben möchten, sollten Sie sich Rhino ETL ansehen.

Ich arbeite auch an meinem eigenen Framework, Fluent ETL , da ich finde, dass SSIS für einfache Datenaufgaben im Zusammenhang mit der Entwicklung, wie das Laden von Unit-Testdaten aus einer CSV-Datei, etwas zu kompliziert ist.

SSIS ist kein Programm. Viele Änderungen sind in SSIS schneller durchzuführen, und Sie erhalten als Administrator sehr schöne detaillierte Fortschritts- und Fehlerinformationen - was in den Szenarien, die SSIS lösen soll, sehr gut sein kann, da manchmal Probleme auftreten und der Administrator viel benötigt Information.

Davon abgesehen ist SSIS nicht wirklich nützlich, wenn Sie das Zeug nicht selbsterklärend haben - sie sind für etwas gedacht, zu viel in die allgemeine Programmierung zu bringen, macht sie nervig.