SQLビューを使用する理由は何ですか？

私はSQL Server 2008の聖書を読んでおり、ビューセクションをカバーしています。しかし、著者は実際にはビューの目的を説明していません。ビューの適切な用途は何ですか？それらを自分のウェブサイトで使用する必要がありますか？それらの利点は何ですか？

前の回答のいずれも言及していないように思われるもう1つの使用法は、テーブル構造の変更を簡単に展開できることです。

たとえば、T_OLDアクティブユーザーのデータを含むテーブル（）を廃止し、代わりに類似したデータ（という名前T_NEW）を持つが、アクティブユーザーと非アクティブユーザーの両方のデータがあり、1つの列が追加された新しいテーブルを使用するとしますactive。

システムにを超える大量のクエリがあるSELECT whatever FROM T_OLD WHERE whatever場合、ロールアウトには次の2つの選択肢があります。

1）コールドトルコ -DBを変更すると同時に、上記のクエリを含む多数のコードを変更、テスト、リリースします。実行するのが非常に難しい（または調整さえも）、非常に危険です。悪い。

2）段階的 -作成することによって変更DB T_NEW、テーブルをドロップT_OLDテーブルを、代わりに作成VIEW呼ばT_OLD模倣することをT_OLDテーブル100％（例えばビュークエリであるとSELECT all_fields_except_active FROM T_NEW WHERE active=1）。

これにより、現在から選択しているコードのリリースを回避し、コードT_OLDを移行するための変更を行うことができますT_OLDにT_NEWレジャーで。

これは簡単な例ですが、もっと複雑な例もあります。

PS一方、おそらく、からの直接クエリの代わりに、ストアドプロシージャAPIT_OLDが必要でしたが、常にそうであるとは限りません。

（Google検索で出てきた最初のチュートリアルからコピーしました（リンクは無効になりました）が、自分で手動で入力した場合のすべての利点があります。）

ビューには次の利点があります。

• セキュリティ-ユーザーはビューにアクセスできますが、基になるテーブルには直接アクセスできません。これにより、DBAは同じテーブル内の他のデータを保護しながら、必要なデータのみをユーザーに提供できます。
• シンプルさ-ビューを使用して、複雑なクエリを非表示にして再利用できます。
• 列名の単純化または明確化-ビューを使用して、列名にエイリアスを提供し、覚えやすく、意味のあるものにすることができます。
• 飛び石-ビューは、「マルチレベル」クエリで飛び石を提供できます。たとえば、各販売員の販売数をカウントするクエリのビューを作成できます。次に、そのビューにクエリを実行して、販売員を販売数でグループ化できます。

ウィキペディアからのいくつかの理由：

ビューはテーブルよりも優れています。

1. ビューは、テーブルに含まれるデータのサブセットを表すことができます
2. ビューは複数のテーブルを結合して単純化し、 単一の仮想テーブルにます
3. ビューは集計テーブルとして機能できます、データベースエンジンがデータ（合計、平均など）を集計し、計算結果をデータの一部ます。
4. ビューはデータの複雑さを隠すことができます。たとえば、ビューはSales2000またはSales2001として表示され、実際の基になるテーブルを透過的に分割できます。
5. ビューの保存に必要なスペースはほとんどありません。データベースにはビューの定義のみが含まれ、ビューが提示するすべてのデータのコピーは含まれません
6. 使用されるSQLエンジンに応じて、ビューは追加のセキュリティを提供できます
7. ビューは、1つまたは複数のテーブルが外部の世界にさらされる度合いを制限する可能性があります

VIEWSはSELECT / CODEの再利用可能なセクションとして使用でき、結合する他の選択/クエリに含めることができ、毎回SELECT全体を再作成する必要なく、さまざまな異なるフィルターを使用できます。

これにより、ロジックが1つの場所に配置されるため、コードベース全体でロジックを変更する必要がなくなります。

見て

ストアドプロシージャ、関数、ビュー、トリガー、インラインSQLからの選択

ビューの主な利点は、ほとんどの状況でテーブルのように使用できることですが、テーブルとは異なり、非常に複雑な計算と一般的に使用される結合をカプセル化できます。また、ストアドプロシージャを除いて、db内のほとんどすべてのオブジェクトを使用できます。ビューは、同じ表のセットを常に結合する必要がある場合に最も役立ちます。たとえば、要約計算フィールドなどを取得するためにOrder Detailを使用したOrderなどです。

ビューは抽象化レイヤーであり、データベーススキーマのカプセル化や内部実装の詳細の変更による影響からユーザーを保護するなど、優れた抽象化レイヤーと同じように機能します。

それはインターフェースです。

ビューを使用してエンティティをいくつかの基準で制約する非常に一般的な1つの使用方法を次に示します。

表：USERSにはすべてのユーザーが含まれます

ビュー：ACTIVE_USERSには、一時停止、禁止、アクティブ化を待機しており、アクティブな要件の一部として将来定義する基準を満たさないユーザーを除くすべてのユーザーが含まれます。これにより、ACTIVE_USERSは常に不要な行を非表示にできるため、削除しないことを選択した場合でも、USERSテーブルから行を削除する必要がなくなります。

このように、ユーザー管理ページでテーブルを使用できますが、アプリケーションの残りの部分は、プロセスを実行してデータにアクセス/変更できる唯一のユーザーである可能性があるため、ACTIVE_USERSを使用できます。

ビューを使用すると、複数の異なるテーブルからのデータを組み合わせてフォーマットし（フィールドを結合し、より意味のあるフィールド名を付けるなど）、エンドユーザーにとってより簡単にすることができます。これらは、データベースモデルを抽象化したものです。また、テーブル自体への直接アクセスをユーザーに与えることなく、テーブル内のデータへのアクセスをユーザーに与えるために使用することもできます。

直接テーブルではなくビューを使用する多くの理由のいくつかを次に示します

• シンプルさ-ビューを使用して、複雑なクエリを非表示にすることができます。
• セキュリティ-ビューは、選択されたいくつかの列にビューを作成することにより、エンドユーザーからいくつかの重要な情報を隠すことができます
• セキュリティ-VIEWを使用してテーブルの構造を変更するための安全なテーブル。
• 冗長性-共通のビューを使用して、すべてのプロシージャ/クエリの冗長コードを削減します。
• 計算-すべての計算は、ビュークエリで一度に実行できます。
• 意味のある名前-テーブルには、[従業員番号]のような別名を付けることができるtbl_org_emp_idのようなIDの名前、または意味のある名前を付けることができます。

imexploring.comから

一般的な理由/用途の小さなリスト：

• それらを使用してデータの形式または「外観」を変更します（つまり、姓と名を結合することができます）

  データの計算やその他の検索を実行する

  データを非正規化する（複数のテーブルから1つのスポットにデータを抽出する）

ビューは悪です！可能であればそれらを避け、DVKで言及されている理由（一時的なデータ移行）にのみ使用してください。

100テーブルのデータベースでは、すべてのテーブルの目的を思い出すのは難しいことを理解する必要があります。ここで、さらに300ビューを追加すると、完全に混乱します。「ビュー愛好家」よりも、ネストされたビューを使用してから、ストアドプロシージャでネストされたビューを使用する傾向があります。私は個人的に、ビューを4回ネストしたデータベースで作業しています。したがって、ストアドプロシージャの最も単純なロジックを理解するには、まずすべてのビューを経由する必要があります。