最近SSISコースを修了しました。ストアドプロシージャとSSISパフォーマンスの埋め込みSQL
私が去ったベストプラクティスの1つは、SSISのデータフロータスクで常にストアドプロシージャを使用することでした。
セキュリティに関する議論があると思いますが、チュートリアルによると、ストアドプロシージャはSQL Serverのすべての作業を "ネイティブ"として実行するため、パフォーマンスが大幅に向上しました。
この点、またはこの点について議論する記事はありますか？
おかげ
は覚えている - 知識を持つ人々が訓練より多くの方に支払うコンサルティングをやってお金を稼ぐため、ほとんどのコースは無知な人々によって行われます。ほとんどのトレーナーは、21ポンドのデータウェアハウスで9ヶ月も費やしていないガラス家屋に住んでいます）
これは間違っています。ポイント。 SQLステートメントは、データベースからデータを取得しない場合にのみ意味があります
- 例えばテーブルのマージなど
そうでない場合、それはあなたがSSIS側の設定方法スマートの質問です。 SSISは、バルクコピーメカニズムを使用して、SQLを使用しないデータを書き込むことができます。 SSISの方がはるかに柔軟性があります。リモートデータベースからデータを取得する場合、データベースを残さない（つまりネイティブを処理する）という議論は、愚かな点です。 SQL Server AからSQL Server Bにデータをコピーすると、BのSPはAネイティブのデータを処理できません。
一般に、Aからデータを取り出してAにプッシュすると、すべての処理を単純なSPで行うことができます（縮退した場合）。
SSISの利点は、データフロー用に設計された環境でデータを処理する柔軟性です。多くの場合、プロジェクトで必要とされ、ストアドプロシージャで必要とすることは悪夢になります。
あなたのスペルが正しいことを確認するための少しの努力は、長い道のりになります。 – JsonStatham
非常に簡単に言えば、データベースからデータを取り出して同じデータベースにプッシュすると、SPが役立ちます。それ以外の場合は、データフロータスクで生のSQLを使用することは「受け入れられる」 –
技術的にはそれがコアです。実際には、データの処理方法にも依存します。 – TomTom
古いスレッドですが、関連トピックです。
データソース接続では、A）ロジックが両方の方法で処理するのに十分シンプルであり、B）SPのサポートがパッケージで作業するより簡単です。 SPがかなり厳密な結果セットを返す場合、データソースのパフォーマンスに大きな違いがあるとは限りません。
私たちのショップでは、パッケージのデプロイプロセスがより複雑になっています。そのため、SPが優先されます。
私はSPをデータの宛先にするために非常に多くのアプリケーションを見つけられませんでした。
興味深いトピック。 –