ビューを使用してテーブルまたはストアドプロシージャを結合して、より優れた実行計画を作成しますか？
まず、私がSQL ServerのDBAではなくC＃の開発者であることを述べさせてください。SQLServerデータベースのクエリ実行プランについての無知を許してください。
私が知りたいのは主キーと外部キーを使用してそれらを参照する2つ以上のテーブルから結果を取得するストアドプロシージャの場合の場合、次のことをお勧めします。
- 結合を実行するビューを持ち、2つ（またはそれ以上）のテーブルからのすべての対応するレコードのフラット化されたデータを含み、stored proc select from and filterそのビュー
- stored procが結合とフィルタリングを行うとします。
C＃の世界では問題を分離するため、1つのオブジェクトまたは関数が結合（この場合はビュー）を担当し、別のオブジェクトまたは関数がフィルタリング（この場合はストアドプロシージャ）を担当するため、 ）。
- 上からどのオプションがより良いパフォーマンスをしますか？
- 上記のどのオプションがベストプラクティスと見なされていますか？
C＃では、パフォーマンスがコードの深刻な問題となっていることが証明されるまで、関心事の分離はパフォーマンスよりも一般的に重要であると考えられています。しかし、SQLの世界で誰が何を積み上げるのかはわかりません！
上記のどのオプションの方がパフォーマンスが良くなりますか？
どちらの場合も、実行時のパフォーマンスは同じで、まったく同じ実行プランが生成されます。
Rob Farleyが 彼の回答 で言及しているように、これには慎重な設計とかなり高度なスキルが必要になる場合があります。 Robは ブログの投稿 にも中核的な問題を説明しており、 SQL Server MVP Deep Dives Volume 1 本の彼の章の1つでも説明されています。
上記のどのオプションがベストプラクティスと見なされますか？
これは、確立されたベストプラクティスのどちらかの方法であるという意見の問題である可能性が高いですが、経験豊富なデータベースプロフェッショナルは、ビューの使用を、実際に大きな利益をもたらすシナリオに制限する傾向があります。ビューが複雑になるほど（特にビューがスタックまたはレイヤー化され始める場合）、望ましくない副作用を回避することが難しくなり、オプティマイザの制限に遭遇する可能性が高くなります。
クエリは、ビューを参照する方が読みやすく、保守も簡単ですが、「懸念の分離」は、ビューを選択するときや、基になるクエリをストアドプロシージャに書き込むときに、データベースの専門家が話し合うものではありません。プログラミングには、データベース作業にうまく対応できない多くの確立されたプラクティスとパターンがあります。
（インデックス付けされていない/マテリアライズされた）ビューは単に保存されたクエリ定義であることを常に心に留めておいてください。クエリのコンパイルと最適化が始まる前に、手動でコピーアンドペーストした場合とまったく同じように、参照クエリに展開されます。
あなたは、ビューを使用することの利点と欠点の包括的な批評を求めなかったので（とにかく質問が広すぎるかもしれません）、私はそれを提供しようとはしません。私の最後の注意点は、今日（おそらくRobのアイデアを利用して）うまく最適化されている単純なビューでも簡単に変更できるため（しばしば無害に見える方法で）、それらを参照するクエリがオプティマイザの制限とパフォーマンスの崖に突然遭遇することです。
http://bit.ly/Simplification で私の講演でビューに関するいくつかの重要なことを示します-重要なことは、不必要な結合を行わないようにし、最適化されるようにすることですこれらの列が必要ない場合。
私の講演では、一般的に開発者向けのインターフェースのモジュール化の概念を取り上げているため、おそらく非常に役立つでしょう。