プログラマーはSSISを使用する必要がありますか？使用する場合、なぜですか？[閉まっている]

.NET開発者として、コードを書くよりもSSISパッケージを好む理由は何ですか？現在私が作業しているパッケージには、大量のパッケージがあり、それらは "書き込み"（おそらく描画？）と維持の両方にとって悪夢です。各パッケージは、抽象化が機能しなくなったポイントでC＃とVB.NETのスクリプトが混在した、色とりどりのスパゲッティのボウルのように見えます。それぞれの「SQLタスクの実行」または「Foreachループ」の機能を理解するには、のろわれたものをダブルクリックし、複数のタブに散らばったリテラル値と式のツリーを参照する必要があります。

私は心を開いているので、他の優れた開発者がコードを書くだけでなくSSISの生産性を高めているかどうか知りたいのですが。SSISの生産性が向上した場合は、その理由を教えてください。

私は毎日SSISを使用して、大規模なデータウェアハウスとキューブを維持および管理しています。私は2年間、100％ビジネスインテリジェンスとデータウェアハウジングを行っています。それ以前は、10の.NETアプリケーション開発者でした。

SSISの価値は、データをある場所から別の場所に移動するためのワークフローエンジンとして、途中で制限された変換と条件付き分岐を使用することです。パッケージに多くのスクリプトが含まれている場合、チームは間違ったタスクにSSISを使用しているか、SQLに慣れていないか、誇大広告を受け入れています。SSISパッケージはデバッグが非常に困難です。スクリプトコンポーネントは絶対的な悪夢であり、フォーマット、ループ、または最後の手段としてのみ使用する必要があります。

1. パッケージをシンプルなSQLタスクとデータフロータスクに保ちます。
2. SSISの外部、できればSQLで可能な限り多くの作業を行う
3. 変数を単一のグローバルスコープに保持する
4. SQLを変数またはストアプロシージャに保持し、インラインにはしない
5. 変数値を構成ストア（できればSQLデータベース）に保管します。

SSISを何度か使ってみましたが、あきらめました。IMO C＃で必要なことをすべて行う方がはるかに簡単です。SSISは複雑すぎて、あまりにも多くの問題があり、それだけの価値はありません。同じ時間をSSISの学習に費やすよりも、C＃スキルの向上により多くの時間を費やす方がはるかに優れています。トレーニングにより多くの利益が得られます。

また、VSソリューションの機能を見つけて維持することは非常に簡単です。VSを使用した単体テストは簡単です。私がしなければならないのは、Subversionでソースをチェックインし、それがどのようにロードされたかを確認することだけです。SSISパッケージの単体テストは、穏やかに行うために非常に複雑です。

さらに、SSISがいくつかの行の一部の列にデータを入力せず、例外を発生させずにスキップするだけの状況がありました。トラブルシューティングと何が起こっているのかを理解するのに多くの時間を費やしました。C＃で代替ソリューションを開発するには1時間もかからず、2年間問題なく機能しました。

私の意見では-SSISはETL操作専用であり、その範囲外のロジックを含むべきではありません。

不幸なことに、SSISが複数のソースからのデータを集約して組み合わせるのに十分なソリューションであると考えるプロジェクトに取り組んだ経験があります。残念なことに、最初はうまく機能したが、その後要件が変更され、最終的にはそれが間違ったツールであることに気付きました。

たぶんそれを誤って使用していたかもしれませんが、スキーマを変更して、最終的にはフロントエンドからORM定義を再利用して、C＃でカスタムツールを作成するだけで多くの困難がありました。すでにデータモデルがあったので、これは驚くほど簡単でした。明らかにYMMVと私は決してSSISのエキスパートではありませんが、この1つのケースでは、SSISは、袖をまくり上げて「ハンドコーディング」するだけで、予想以上に簡単に多くの重複作業と頭痛を引き起こしました。

したがって、SSISを検討するときは、柔軟性についてよく考えます。

SSISにはその場所があり、その場所は一般的なプログラミングやストアドプロシージャの代わりにはなりません。それはETLスクール（Extract、Transform、およびLoad）から来ており、それがその強みです。

古い名前（DTS、データ変換サービス）と新しい名前（SSIS、Sql Server Integration Services）はどちらも、データを操作してSQL Serverデータベースをより大きなプロセスに統合するように設計されたサービス（またはサービスのセット）であることを明確に示しています。

プログラムでデータを移動する場合は、Rhino ETLを確認することをお勧めします。

また、CSVファイルからの単体テストデータの読み込みなど、開発に関連する単純なデータタスクにはSSISが少し複雑すぎるため、独自のフレームワークであるFluent ETLにも取り組んでいます。

SSISはプログラムではありません。SSISの方が多くの修正が高速であり、管理者として非常に詳細な進行状況とエラー情報を取得できます。これは、SSISが解決しようとしているシナリオで非常に役立ちます。情報。

そうは言っても、SSISは、説明が必要なものがない場合、それほど有用ではありません。これらは何かのためのものであり、一般的なプログラミングに過度に取り組むと、厄介なものになります。