I programmatori dovrebbero usare SSIS e, in caso affermativo, perché? [chiuso]

In qualità di sviluppatore .NET, per quali motivi dovrei preferire i pacchetti SSIS alla scrittura di codice? Abbiamo un sacco di pacchetti in produzione dove attualmente lavoro, e sono un incubo sia da "scrivere" (forse disegnare?) Che da mantenere. Ogni pacchetto sembra una ciotola di spaghetti multicolori con script C # e VB.NET mescolati nei punti in cui le astrazioni si scompongono. Per capire cosa fa ogni "Esegui attività SQL" o "Foreach Loop", devo fare doppio clic sulla dannata cosa e sfogliare un albero di valori ed espressioni letterali, sparsi su più schede.

Sono di mentalità aperta, quindi mi piacerebbe sapere se altri bravi sviluppatori trovano SSIS più produttivo della semplice scrittura di codice. Se ritieni che SSIS sia più produttivo, dimmi perché.

Uso SSIS ogni giorno per mantenere e gestire un grande data warehouse e cubo. Sono stato al 100% business intelligence e data warehousing da due anni. Prima di allora ero uno sviluppatore di applicazioni .NET per 10.

Il valore di SSIS è come un motore di flusso di lavoro per spostare i dati da un punto a un altro con forse qualche trasformazione limitata e diramazioni condizionali lungo il percorso. Se i tuoi pacchetti contengono molti script, il tuo team sta usando SSIS per le attività sbagliate o non è a suo agio con SQL o è entrato nel clamore. I pacchetti SSIS sono molto difficili da eseguire il debug. I componenti dello script sono un incubo assoluto e dovrebbero essere usati solo per la formattazione, il loop o come ultima risorsa.

1. Mantieni i tuoi pacchetti semplici, attività SQL e attività del flusso di dati.
2. Eseguire quanto più lavoro possibile al di fuori di SSIS, preferibilmente in SQL
3. Mantieni le tue variabili in un unico ambito globale
4. Mantieni il tuo SQL in variabili o archivia procedure, mai in linea
5. Conserva i valori delle tue variabili in un archivio di configurazione, preferibilmente un database SQL

Ho provato a utilizzare SSIS diverse volte e ci ho rinunciato. IMO è molto più semplice fare tutto ciò di cui ho bisogno in C #. SSIS è troppo complesso, ha troppi trucchi e non ne vale la pena. È molto meglio dedicare più tempo al miglioramento delle competenze C # piuttosto che dedicare lo stesso tempo all'apprendimento di SSIS: otterrai molto più ritorno sulla tua formazione.

Inoltre, trovare e mantenere le funzionalità in una soluzione VS è molto più semplice. Il test unitario con VS è facile. Tutto quello che devo fare è controllare il sorgente in Subversion e verificare come è stato caricato. I pacchetti SSIS di test unitario sono molto coinvolti per usare un eufemismo.

Inoltre, c'erano situazioni in cui SSIS non riusciva silenziosamente a popolare alcune colonne in alcune righe, saltandole semplicemente senza sollevare eccezioni. Abbiamo trascorso molto tempo a risolvere i problemi e a capire cosa stava succedendo. Lo sviluppo di una soluzione alternativa in C # ha richiesto meno di un'ora e funziona senza problemi per due anni.

A mio parere, SSIS è solo per operazioni ETL e non dovrebbe contenere alcuna logica al di fuori di tale ambito.

Ho avuto la sfortunata esperienza di lavorare a un progetto in cui pensavamo che SSIS sarebbe stata una soluzione abbastanza buona per aggregare e combinare i dati da diverse fonti. La cosa sfortunata è che all'inizio funzionava alla grande, ma poi i requisiti sono cambiati e alla fine ci siamo resi conto che era lo strumento sbagliato.

forse lo stavamo usando in modo errato ma abbiamo avuto molte difficoltà se avessimo cambiato il nostro schema e alla fine abbiamo semplicemente riutilizzato le nostre definizioni ORM dal front-end per scrivere uno strumento personalizzato in C # per farlo. Poiché avevamo già il modello di dati, è stato sorprendentemente facile. ovviamente YMMV e io non siamo affatto un esperto di SSIS, ma in questo caso SSIS ha causato un sacco di lavoro duplicato e mal di testa quando solo rimboccarsi le maniche e "codificare a mano" era più facile del previsto.

Quindi penserei molto alla flessibilità quando si considera SSIS.

SSIS ha il suo posto e quel posto non è una programmazione generale o una sostituzione per le stored procedure. Proviene dalla scuola ETL (Extract, Transform, and Load) ed è lì che si trova la sua strada.

Il vecchio nome (DTS, Data Transformation Services) e il nuovo nome (SSIS, Sql Server Integration Services) chiariscono entrambi che si tratta di un servizio (o insieme di servizi) progettato per manipolare i dati per integrare il database di SQL Server in processi più grandi.

Se desideri spostare i tuoi dati in modo programmatico, potresti dare un'occhiata a Rhino ETL.

Sto anche lavorando sul mio framework, Fluent ETL , poiché trovo SSIS un po 'troppo coinvolto per semplici attività di dati relative allo sviluppo, come il caricamento dei dati di unit test da un file CSV.

SSIS non è un programma. Molte cose sono più veloci da fare in SSIS e si ottengono informazioni dettagliate sull'avanzamento e sugli errori come amministratore, il che può essere molto buono negli scenari che SSIS è destinato a risolvere, perché a volte le cose vanno storte e l'amministratore ha bisogno di molte informazione.

Detto questo, SSIS non è davvero così utile se non hai le cose che si auto-spiegano - sono pensate per qualcosa, entrare troppo nella programmazione generale le fa schifo.