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