9

最近、SSIS コースを修了しました。

私が思いついたベスト プラクティスの 1 つは、SSIS のデータ フロー タスクで常にストアド プロシージャを使用することでした。

セキュリティに関しては議論があると思いますが、ストアドプロシージャがすべての作業をSQL Server上で「ネイティブ」に実行したため、パフォーマンスが大幅に向上した/されていると講師は言いました。

この点、またはその点を議論する記事に真実はありますか?

ありがとう

4

2 に答える 2

5

覚えておいてください - ほとんどのコースは無知な人々によって行われます. ほとんどのトレーナーは、21 TB のデータ ウェアハウスに 9 か月も費やすことのないグラスハウスに住んでいます ;)

これは間違っています。点。

SQLステートメントがデータベースからデータを取得しない場合にのみ意味があります-たとえば、テーブルのマージなど.

それ以外の場合は、SSIS 側をどれだけ賢く設定するかが問題になります。SSIS は、一括コピー メカニズムを使用して、SQL を使用せずにデータを書き込むことができます。SSIS ははるかに柔軟性があり、リモート データベースからデータを取得する場合、データベースを離れない (つまり、ネイティブで処理する) という議論は愚かな指摘です。SQL Server A から SQL Server B にデータをコピーすると、B 上の SP は A ネイティブからのデータを処理できません。

一般に、FROM A からデータを取得して A にプッシュし、すべての処理を単純な SP で実行できる場合にのみ高速になります。

SSIS の利点は、データ フロー用に設計された環境でデータを処理できる柔軟性です。これは多くの場合、プロジェクトで必要とされ、ストアド プロシージャでそれを行うと悪夢になります。

于 2012-07-06T09:53:06.450 に答える
2

古いスレッドですが、適切なトピックです。

データ ソース接続の場合、A) 両方の方法で処理できるほどロジックが単純であり、B) SP のサポートがパッケージを操作するよりも簡単である場合、埋め込みクエリよりも SP を好みます。SP がかなり単純な結果セットを返す場合、データ ソースのパフォーマンスに大きな違いはありませんでした。

私たちのショップには、より複雑なパッケージの展開プロセスがあるため、SP が優先ソースになります。

SP をデータ宛先として使用するアプリケーションはあまり多くありませんが、場合によってはロギング SP 呼び出しが必要になる場合があります。

于 2015-04-23T01:25:43.223 に答える