SQL ServerのプログラムによるETLの標準言語/インターフェイスはありますか？

現在、データウェアハウス用のETLを作成しています。SSIS 2008を使用していますが、問題が発生しています。最大の問題は、コンポーネントの再利用の難しさです。テーブルごとに個別のパッケージがあり、各パッケージは親パッケージからいくつかの変数を入力として受け取ります。これらの入力変数に変更を加えるときは、各パッケージ（15ほどありますが、この数は大幅に増える予定です）に移動し、パッケージを変更してそれらの変更に対処する必要があります。他の問題もあります。たとえば、抽出のために任意のSQLを実行できない、ログ機能が不十分などです。

このプロセス全体は、コードでETLを開発し、コードの再利用、共通ライブラリ、より優れた単体テストなどを可能にする方法があれば、はるかに堅牢になります。SQLServerの事実上の標準ETL言語/ APIはありますか？GUIツールはできるだけ避けたいです。

編集：私は自分の経歴について述べるべきです。私はDBAではなく、正式な（または非公式の）DBAトレーニングを受けていません。基本的に、私はこれを理解していて、SSISで不適切なことを試みたり、このETLに近づいたりする可能性があります間違った角度から投影します。また、私は現在州政府で雇用されているため、新しいソフトウェアパッケージの購入を必要とするソリューションは、可能性の範囲内にありません。

これが私たちのタスクの1つです。単一のSSISパッケージを使用して、ウェアハウスの各テーブルをロードしています。各ファクトパッケージとディメンションパッケージは一般的に同じですが、

• ソースデータベースからの抽出
• データフローでの操作
• 宛先テーブルにマージします

できること（SSISで実行するのが難しいと感じていること）

• テキストファイルから抽出クエリを読み込みます。開発者が抽出クエリを作成してテストする場合、SSISで実行する前にクエリを操作する必要はなく、クエリを切り取ってDBソースオブジェクトに貼り付ける必要もありません。
• 各コンポーネントを個別にテストします。他のテーブルのロードとは無関係に、個々のテーブルの完全なETLプロセスを分離してテストできるはずです。
• 1つの場所で共有ロジックを変更します。個々のパッケージを編集する必要はありません。すべてのパッケージが同じ方法でデータを監査テーブルにロードします。監査されてロードされたデータを変更したい場合、15個すべてのパッケージを編集する必要はありません（この数は時間とともにかなり大きくなります）。

プロセス全体は、共有コードを適切に使用してプログラム的に行うと、実装がはるかに簡単になり、より堅牢になると感じています。

これを可能にするツールがあります-http://www.varigence.com/products/biml.html

商用バージョンがありますが、無料のツールであるBIDS HelperにBIML機能の一部も含まれています。http://bidshelper.codeplex.com/

あなたがそれについて持っているかもしれないどんな質問にでも答えたいです。

これは私の会社が提供するツールです。

これを読んだとき、私はすぐにバリジェンスのツールを勧めることを考えました。しかし、私はVarigenceの主任建築家の1人であるJohn Welchが私の前にここに来たと思います。

Varigenceのツールは、SSISの上の抽象化レイヤーです。それが提供する利点は、再利用可能な「もの」を定義する機能であり、したがって複数のパッケージにわたって一貫性を提供します。パッケージをどのように構造化するか、また個々のパッケージでどのように異なるかを定義します。Varigenceのツールからの「コンパイル済み」出力はSSISパッケージです。

SSISパッケージ用の動的SQLと考えてください。GUI付き。本当にすごい。

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

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

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

また、Rhino ETLは本当にクールなようです。

stackoverflowについても同様の議論がいくつかありました。

個人的には、SQLで可能な限り多くのETLプロセスを処理します。FTPサイトやExcelなどの奇妙なデータソースからインポートするためにSSISを使用していますが、それはSQLが残りの処理を行うデータベースに生データを取得するためだけです。

私の現在の状況は、ほとんどのデータが他のMS SQLデータベースにあり、リンクサーバーをセットアップできるという点で、比較的単純です。他のプラットフォームに接続する必要がある場合は、OPENQUERYおよびを使用することをお勧めしBULK INSERTます。これらは必要に応じてプログラムで構築でき、2つの間でほとんどのタイプのデータに接続できます。

私がSQLを使用しているのは、それが私が最もよく知っているものだからですが、いくつかの客観的な利点があります。最も注目に値するのは、すでに使用されていることです。新しいツールについて学習したり、料金を支払う必要はありません。これは広く利用可能なスキルであり、上司にとっては重要ではありません。データベースで動作するため、ロギングが容易です。プレーンテキストコードに基づいているため、簡単に検索でき、ソース管理とうまく連携します。これは非常に安定しており、ベンダーが変更したり、下位互換性を壊したりする可能性はほとんどありません。おそらく、少なくとも他のRBAR言語と同じくらい高速です。

さらに必要な場合は、SNETおよびSQLCLRで使用されているという理由だけで、.NETをお勧めします。私はC＃アプリを使用して、ETLプロセス全体を管理します-サブステップの開始、出力の監視、電子メールの送信。しかし、これのほとんどすべては、SQLエージェント、dbmailなどで行うことができます。

ETLにSQLを使用できない理由はありますか？あなたのために何ができなかったのですか？