私は8つの異なるビューを作成し、ビュー内でこれらすべてのビューを使用しています。だから私はこのアイデアをさらに進める前に疑問に思っていました。パフォーマンスに悪影響を与えるかどうかを知りたいです。
5 に答える
大丈夫です。多くの場合、私は個人的に、巨大で理解しにくい定義で1つのビューを書く方が好ましいと考えています。私の意見では、複数のビューを使用すると、次のことが可能になります。
- 個別のロジックを個々のビューにカプセル化します。
- ロジックを繰り返すことなく、個々のビューでロジックを再利用します(後で更新の問題を排除します)。
- 次のプログラマーがあなたが達成しようとしていたことを理解しやすいように、ロジックに名前を付けます。
ビューは、実行プランの作成中に「コンパイル」されます。したがって、それらを使用する場合のペナルティはごくわずかです。SQLServerが定義を検索するのに余分な時間がかかります。通常、この遅延は測定できません。
つまり、Larry Lustigが言及した目的でビューを使用することは、まったく問題がなく、奨励できることを意味します。
ただし、この手法を使用して不要なJOINを導入しないようにしてください。SQL Serverには、クエリから不要なテーブルを削除するメカニズムがありますが、クエリが複雑になるとすぐに諦めます。これらの追加のJOINを実行すると、大幅な速度低下が発生する可能性があります。これが、多くの企業がノービュールールを導入している理由です。
したがって、ビューを使用しますが、誤用しないように注意してください。
ビューであるだけでパフォーマンスが低下することはありません。維持するのがいくらか複雑になる可能性があり、基になるテーブルのスキーマを変更する場合は追加の考慮事項が発生する可能性があります。ビューを使用していて、それらが同じテーブルに結合されている場合、1つのビューで一度テーブルに結合するよりも効率が悪いと思います。
ネストされたビューを使用することを好みます。各ビューは、データの一部の断面をカプセル化して名前を付けます。
パフォーマンスに関しては、代替手段で同じデータを複数回クエリする必要がある場合、実際にパフォーマンスを向上させることができます。ネストされたビューは、一時テーブルに少し似ています-1回起動されます。
パフォーマンスへの影響を発見するための最良の、そして推奨される方法は、両方のオプションを試して、explain出力を調べることです。
ビュー内からビューをクエリするという純粋な事実は、パフォーマンスに悪影響を及ぼしません。ビュー内からテーブルをクエリするのと同じです。