ストアドプロシージャと視聴回数
私は両方を使用しましたが、はっきりしないのは、どちらを優先するかです。つまり、ストアドプロシージャがパラメータを取得できることはわかっていますが、実際にはビューを使用しても同じことを実行できますか？
だから、パフォーマンスと他の側面を考慮すると、いつ、なぜ私は一方よりもどちらを好むべきですか？
さて、コードのカプセル化とアクセス許可の制御にはストアドプロシージャを使用します。
ビューは実際にはカプセル化ではありません。それは拡張するマクロです。ビューへの参加をすぐに開始すると、いくつかの恐ろしいクエリが発生します。はい、彼らはcan参加できますが、そうすべきではありません。
つまり、ビューは、ストアドプロシージャのような場所（たとえば、インデックス付きビュー）を持つツールです。
ビューの利点は、テーブルのように扱うことができることです。 WHEREを使用して、フィルターされたデータを取得したり、JOINしたりできます。それらが十分に単純であれば、それらにデータを挿入することもできます。ビューでは、ストアドプロシージャとは異なり、結果にインデックスを付けることもできます。
ビューは、保存された単一のクエリステートメントのようなものであり、複雑なロジックや複数のステートメントを含めることはできません（ユニオンなどの使用以外）。パラメータを介して複雑またはカスタマイズ可能なものについては、はるかに高い柔軟性を可能にするストアドプロシージャを選択します。
データベースアーキテクチャでビューとストアドプロシージャの組み合わせを使用することはよくありますが、おそらく非常に異なる理由があります。スキーマの再設計時にsprocの下位互換性を実現することもあれば、データをテーブルにネイティブに保存する方法（非正規化ビュー）と比較して操作しやすくすることもあります。
ビューを頻繁に使用すると、SQL Serverがこれらのクエリを最適化することが難しくなるため、パフォーマンスが低下する可能性があります。ただし、インデックス付きテーブルと同じ方法で結合を操作する場合、実際にパフォーマンスを向上させることができるインデックス付きビューを使用することができます。インデックス付きビューを実装する際に許可される構文にはさらに厳しい制限があり、SQL Serverのエディションに応じて実際に機能させるには多くの微妙な点があります。
ビューは、ストアドプロシージャというよりもテーブルのようなものだと考えてください。
ストアドプロシージャの主な利点は、ロジック（スクリプト）を組み込むことができることです。このロジックは、IF/ELSEのような単純なものでも、DO WHILEループ、SWITCH/CASEなどのより複雑なものでもかまいません。
ストアドプロシージャの使用を、データベースとの間でトランザクションを送受信する必要性に関連付けます。つまり、データベースにデータを送信する必要があるときはいつでも、ストアドプロシージャを使用します。データを更新したり、アプリケーションで使用する情報をデータベースに照会したりする場合も同様です。
データベースビューは、特定のテーブルのフィールドのサブセットを提供し、MS Accessユーザーがデータを変更するリスクなしに表示できるようにし、レポートが確実に結果を生成するようにする場合に使用すると便利です。
ビューは、テーブルの特定の組み合わせ、または一貫してクエリを実行するデータのサブセット（たとえば、ユーザーがそのアクセス許可で結合されている）がある場合に役立ちます。実際、ビューはテーブルとして扱われるべきです。
ストアドプロシージャは、ランダムに他のクエリよりも最適に実行するために、「コンパイル」されたSQLコードの一部です。ストアドプロシージャ内のSQLコードの実行プランは既に構築されているため、実行は通常のSQLステートメントの実行よりもわずかにスムーズに実行されます。
2つの理論的根拠。
挿入を許可しない場合は、ビューの代わりにストアドプロシージャを使用します。ビューに挿入しても、ビューが何をしているように見えるかはわかりません。ビューのクエリに一致しない行、テーブルに表示されない行、テーブルに挿入します。どこかに挿入しますが、ステートメントがそれを思わせる場所には挿入しません。
別のストアドプロシージャのストアドプロシージャの結果を使用できない場合は、ビューを使用します（少なくともMySQLでは、後者を機能させることはできませんでした）。