データベースビューを使用する場合と使用しない場合
この質問はデータベースビューに関するものですnotマテリアライズドビュー。
長所：
- クエリの簡略化。
- 複数のクエリで同じ結合を繰り返すことは避けてください。
- マジックナンバーは避けてください。
短所：
- 実際のクエリを非表示にします（結合を繰り返している可能性があります）。
ほかに何か？
長所：アプリケーションが使用しているクエリに影響を与えることなく、基になるデータ構造を変更できます（ビューがデータ構造を非表示にできる限り）
セキュリティ。ビューから返された列を表示できるはずのユーザーに、ビューへのアクセスを許可します。
データベースにクエリを送信するパーティを完全に信頼していない場合、ビューは非常に優れています。良い例は、請負業者のテーブルにビューを作成して、請負業者が見ることができるのはプロジェクトに関連する行だけになるようにすることです。
ビューは複雑さと複数の結合を隠すことができますが、これらはとにかくSPにあったであろう複雑さです。
SPを最適化できた場合は、ビューを最適化する必要があります。これにより、そのビューにヒットするすべてのSPのパフォーマンスが向上します。
ビューは、他のすべての非常に良い理由よりも際立っている1つの理由で、信じられないほど強力で便利です。それらはコードの重複を減らします。つまり、ほとんどの場合、収益です。クエリが3つ以上の場所で使用される場合、スキーマまたはクエリパラメータが変更されると、ビューによって変更が大幅に簡素化されます。
クエリロジックを変更するには、22個のストアドプロシージャを編集する必要がありました。元のアーキテクチャがビューを利用していた場合、変更は3つしかありませんでした。
SQL Serverに 共通テーブル式 が追加されたので、作成するビューが少なくなりました。ビューを作成するときは、通常、1つのクエリを置き換えるものではなく、多くのクエリで使用できる正規化された階層用です。
たとえば、Region、Market、Cityは、3つの正規化されたテーブル（スノーフレーク）である場合があります。クエリの90％がこのデータを必要としているので、ビューを作成します。ビューが単一のクエリを置き換えることはありませんが、他のすべてのクエリを単純にしてDRYにします。
奇妙な結合やエイリアスによるグループ化を行うために、ビューを数回使用する必要がありました。
奇妙な結合とは、個別の日付のリストを選択し、それらを元のテーブルに外部結合して、空の日のnullエントリを取得することを意味します。私はそれを行う他の方法を理解することができませんでした。
エイリアスによるグループ化については、エイリアス内の式の複雑さに依存しているようです。エイリアスが実際の列、またはすでにグループ化されている列を参照していなかった場合、すべて問題ありませんでしたが、グループ化に含まれていない列のエイリアスはエラーをスローしていました。
大学時代のどこかで、結合されたテーブルから選択するよりもビューから選択する方が速いと読んだり聞いたりしたことを覚えているようですが、それが本当かどうかはわかりません。
ビューを使用する最後の利点は、Excelのピボットテーブルです。テーブルを結合する方法はないと思います。少なくともウィザードのインターフェイスにはありません。 Microsoft Queryで結合を行うことは可能かもしれませんが、今考えたばかりなので、まだ試していません。
以前はずっと使っていましたが、今ではめったに使いません。ただし、すべてのデータアクセスはストアドプロシージャを介して行うため、SPは必要に応じて結合の複雑さを隠すことができるため、ビューの有用性はやや低くなります。
多くのテーブルが特に複雑に結合されていて、その上に多くのSPを構築する必要がある場合は、ビューの使用を検討しますが、正直なところ、現在本番環境にあるものは考えられません。 。
もう1つのシナリオは、ユーザーが独自のレポートを生成するためにデータベースにアクセスできる場合に使用し、ユーザーの根本的な複雑さを隠したいと思います。