web-dev-qa-db-ja.com

SqlServerビューを使用することの欠点は何ですか？

SqlServerビューを使用することの欠点は何ですか？

データを非正規化された形式で表示するために、ビューを頻繁に作成します。

多くのテーブル間で複雑な結合を使用する複雑なクエリを生成するよりも、これらの結合の1つをクエリする方がはるかに簡単で、したがって高速で、エラーが発生しにくく、自己文書化が進んでいます。特に、同じデータ（多くの同じフィールド、同じテーブル結合）をさまざまな角度から分析している場合。

しかし、これらのビューを作成して使用するにはコストがかかりますか？

クエリ処理を遅く（または速く？）していますか？

sql-servertsqlviewsperformance
25
Lill Lansey

ビューに関しては、長所と短所があります。

利点：

  1. これらは仮想テーブルであり、個別のオブジェクトとしてデータベースに保存されません。保存されるのはSELECTステートメントだけです。
  2. ユーザーが見ることができるものを制限することにより、セキュリティ対策として使用できます。
  3. 一般的に使用される複雑なクエリをビューにカプセル化することで、読みやすくすることができます。ただし、これは両刃の剣です。欠点＃3を参照してください。

短所：

  1. 最適化された実行プランがキャッシュされていないため、ストアドプロシージャほど高速ではありません。
  2. これは基本的にSELECTの単なる抽象化であるため、純粋なSELECTを実行するよりもわずかに遅くなります。
  3. それは複雑さを隠し、落とし穴につながる可能性があります。 （Gotcha：ORDER BYは尊重されません）。

私の個人的な意見は、ビューを使用するのではなく、ビューのセキュリティとカプセル化を提供するだけでなく、パフォーマンスも向上するストアドプロシージャを使用することです。

20
hyprsleepy

ビューを使用することの考えられる欠点の1つは、基礎となる設計の複雑さを抽象化することです。これは、ジュニア開発者やレポート作成者による悪用につながる可能性があります。

特に大規模で複雑なプロジェクトのために、私は一連のビューを設計しました。これらのビューは、主にレポート設計者がCrystalレポートに入力するために使用します。数週間後、ジュニア開発者がこれらのビューを使用して集計をフェッチし、すでに大きいビューが存在していて使いやすいという理由だけでそれらを結合し始めていることがわかりました。 （データベースにはEAV設計の強力な要素がありました。）ジュニア開発者が、一見単純なレポートの実行に何分もかかるのかと尋ね始めた後、私はこれについて知りました。

12
Paul Sasik

ビューの効率は、基になるテーブルに大きく依存します。ビューは実際には、クエリ結果を表示するための組織化された一貫した方法です。ビューの形成に使用されるクエリが適切であり、基になるテーブルで適切なインデックスを使用している場合、ビューがパフォーマンスに悪影響を与えることはありません。

SQL Serverでは、 マテリアライズドビューまたはインデックス付きビューを作成 （SQL Server 2000以降）も可能です。これにより、速度がいくらか向上します。

7
JNK

ビューに、最終的なクエリで最終的に使用されないロジック、列、行、またはテーブルが含まれている場合、ビューはパフォーマンスを低下させる可能性があります。次のようなものを見た回数はわかりません。

SELECT ... 
FROM (View with complex UNION of ActiveCustomer and InactiveCustomer tables)
WHERE Active = True

（したがって、InactiveCustomerテーブルからビューに含まれていたすべての行を除外します）、または

SELECT (one column)
FROM (view that returns 50 columns)

（SQLは大量のデータを取得する必要があり、それは後のステップで破棄されます。ブックマークのルックアップなど、他の列の取得にはコストがかかる可能性があります）、または

SELECT ...
FROM (view with complex filters)
WHERE (entirely different filters)

（テーブルが直接クエリされた場合、SQLはより適切なインデックスを使用できた可能性があります）、または

SELECT (only fields from a single table)
FROM (view that contains crazy complex joins)

（結合によるCPUオーバーヘッドが多く、後で破棄されるテーブル読み取りには不要なIO）、または私のお気に入り：

SELECT ...
FROM (Crazy UNION of 12 tables each containing a month of data)
WHERE OrderDate = @OrderDate

（実際に1を読み取る必要がある場合にのみ、12のテーブルを読み取ります）。

ほとんどの場合、SQLは「カバーを透視」し、とにかく効果的なクエリプランを考え出すのに十分賢いです。しかし、他の場合（特に非常に複雑な場合）はできません。上記の各状況での答えは、ビューを削除し、代わりに基になるテーブルにクエリを実行することでした。

少なくとも（とにかくSQLを最適化するのに十分賢いと思う場合でも）、ビューを削除すると、独自のクエリのデバッグと最適化が簡単になる場合があります（何をする必要があるかが少しわかりやすくなります）。 ）。

4
BradC

私も定期的にビューを使用しています。ただし、基になるテーブルが頻繁に（特に開発中に）変更される場合、多くのビューを使用することを維持するのが難しい可能性があることに注意してください。

編集：そうは言っても、複雑なクエリを単純化して再利用できるという便利さと利点は、特にビューが責任を持って使用される場合、メンテナンスの問題よりも重要であることがわかりました。

4
dotariel

私が遭遇したビューの欠点は、それらを分散クエリに組み込む際のパフォーマンスの低下です。この SQLMag の記事で説明します-デモでは高度に人工的なデータを使用していますが、「現実の世界」でこの問題に何度も遭遇しました。

あなたの意見を尊重してください、そうすれば彼らはあなたをよく扱います。

3
Will A

SQL Serverのビューのさまざまな制限は何ですか？

ビューの上位11の制限

  • ビューはCOUNT（）;をサポートしていません。ただし、COUNT_BIGをサポートできます（）
  • ORDERBY句はビューでは機能しません
  • 通常のクエリまたはストアドプロシージャは、別の列が必要なときに柔軟性を提供します。通常のクエリにすぐに列を追加できます。ビューで同じことをしたい場合は、最初にビューを変更する必要があります
  • ビューで作成されたインデックスはあまり使用されません
  • ビューが作成され、基本テーブルに列が追加または削除されている場合、通常、更新されるまでビューに反映されません。
  • UNION操作はインデックスビューでは許可されていません
  • ネストされたビューの状況でインデックスを作成できないということは、別のビューから作成されたビューにインデックスを作成できないことを意味します。
  • インデックス付きビューでは自己結合は許可されていません
  • インデックス付きビューでは外部結合は許可されていません
  • インデックス付きビューではデータベース間クエリは許可されていません

ソースSQL MVP Pinal Dave

http://blog.sqlauthority.com/2010/10/03/sql-server-the-limitations-of-the-views-eleven-and-more/

3
Bryan Swan

私が始めたとき、ビューはパフォーマンスのオーバーヘッドを追加しましたが、経験は別のストーリーを描きます（ビューメカニズム自体のオーバーヘッドはごくわずかです）。

それはすべて、基になるクエリが何であるかに依存します。インデックス付きビューを確認してください ここ または ここ 、最終的には、明確なパフォーマンスプロファイルを取得するために、両方の方法でパフォーマンスをテストする必要があります

1
Mr Shoubs

私の最大の「不満」は、ORDERBYがビューで機能しないことです。それは理にかなっていますが、予期しない場合にジャンプして噛む可能性がある場合です。このため、いくつかのケースで、ビューの使用からSPROCS（独自の問題が十分にある）にawayを切り替える必要がありました。後でORDERBYを指定しないでください。 （「FINALVIEW」を含む構成があればいいのにと思います。たとえば、order by--セマンティクスを含めることができます）。

http://blog.sqlauthority.com/2010/10/03/sql-server-the-limitations-of-the-views-eleven-and-more/ （制限＃1はORDERに関するものです沿って ：-）

0
user166390