ビューにはいくつかの利点があります。
1.ビューは複雑さを隠すことができます
複数のテーブルを結合する必要があるクエリ、または複雑なロジックや計算があるクエリがある場合は、そのロジックすべてをビューにコーディングしてから、テーブルと同じようにビューから選択できます。
2。ビューはセキュリティメカニズムとして使用できます
ビューは、テーブルから特定の列または行、あるいはその両方を選択したり、ビューを基になるテーブルの代わりにビューに設定したりできます。これにより、ユーザーが表示する必要があるデータだけを表示できます。
.ビューはレガシーコードのサポートを簡素化できます
多くのコードを破壊するようなテーブルをリファクタリングする必要がある場合は、テーブルを同じ名前のビューに置き換えることができます。実際のスキーマは変更されていますが、ビューは元のテーブルとまったく同じスキーマを提供します。これにより、テーブルを参照するレガシコードが破損しないようにして、レガシコードを自由に変更できるようになります。
これらは、ビューがどのように役立つ可能性があるかに関する多くの例のほんの一部にすぎません。
とりわけセキュリティのために使用することができます。 「顧客」テーブルがある場合は、すべての営業担当者に名前、住所、郵便番号などのフィールドへのアクセス権を付与し、credit_card_numberには付与したくない場合があります。アクセスが必要な列のみを含むビューを作成してから、それらのビューにアクセスを許可することができます。
ビューはクエリをカプセル化したものです。ビューに変換されるクエリは複雑になる傾向があり、そのためクエリを再利用のためのビューとして保存すると効果的な場合があります。
私は通常、レポート目的で頻繁に使用されるデータを非正規化または集計するためのビューを作成します。
EDIT
詳細には、個人、会社、役割、所有者の種類、注文、注文の詳細、住所、電話などのエンティティが含まれるデータベースがあるとします。ここで、personテーブルには従業員と連絡先、住所と住所の両方が格納されます。電話テーブルには個人と会社の両方の電話番号が格納されており、開発チームは従業員ごとの売上、顧客ごとの売上、地域ごとの売上、月ごとの売上などのレポートの生成（または開発者以外のユーザーによるレポートデータへのアクセス）私は、データベースエンティティ間の関係を非正規化する一連のビューを作成して、現実世界のエンティティのより統合されたビュー（意図しない）が利用可能になるようにします。いくつかの利点があります。
- クエリを書く際の冗長性を減らす
- 関連事業体のための基準の確立
- 複雑な計算や結合のパフォーマンスを評価して最大化する機会を提供する（例：MSSQLのSchemaboundビューのインデックス作成）
- チームメンバーや非開発者にとって、データをよりアクセスしやすく直観的にすることができます。
いくつかの理由：複雑な結合がある場合は、どのアクセスでも結合が正しく、開発者が必要とする可能性のあるすべてのテーブルを覚えておく必要がないようにビューを表示するのが最善の場合があります。通常これは、すべての財務レポートが同じデータセットに基づいていることが非常に重要になるような財務アプリケーションのためのものです。
表示できるレコードを制限したいユーザーがいる場合は、ビューを使用して、基礎となるテーブルではなくそのビューのみにアクセスを許可してからビューを照会することができます。
Crystalレポートはストアドプロシージャにビューを使用することを好むように思われるため、多くのレポート作成を行う人々は多くのビューを使用する傾向があります。
データベースをリファクタリングするときにも、ビューは非常に便利です。ビューを作成することで、古いコードが変更を認識しないように、変更を非表示にすることができます。データベースのリファクタリングを読んで、これがリファクタリングを行うための非常に強力な方法であることを確認してください。
ストアドプロシージャに対するビューの大きな利点の1つは、テーブルを使用するのと同じようにビューを使用できることです。つまり、ビューはクエリのFROM句で直接参照できます。例：SELECT * FROM dbo.name_of_view.
他のほとんどすべての点で、ストアドプロシージャはより強力です。 out、SELECT、INSERT、UPDATEなどの操作を行うことで、一度に複数の値を効果的に返すことができるDELETEパラメータなど、パラメータを渡すことができます。
ビューのFROM句内からクエリを実行できるようにしたいが、パラメータを渡すこともできるようにしたい場合は、それを実行する方法もあります。これはテーブル値関数と呼ばれています。
これは、このトピックに関する非常に役に立つ記事です。
編集：ところで、この種の問題は、テーブル値関数に比べてビューにはどのような利点があるのでしょうか。あまり良い答えはありませんが、ビューを作成するためのT-SQL構文はテーブル値関数よりも単純であり、データベースのユーザーはビューに慣れている可能性があります。
それはあなたのORMとあなたのテーブルの間の良い「仲介人」として機能することができます。
例：
SomeColumn列が別のテーブルに移動され、1対多の関係になるように、Personテーブルを作成して構造を変更する必要がありました。
しかし、Personに関しては、システムの大部分がSomeColumnを単一のものとして使用していました。多くのものではありませんでした。いくつかのSomeColumnsをまとめてビューに配置するためにビューを使用しました。
これは、データ層が変更されたがビジネス要件が根本的に変更されていないために機能し、ビジネスオブジェクトを変更する必要はありません。ビジネスオブジェクトを変更しなければならない場合、これが実行可能な解決策になるとは思われませんが、ビューは確かに良い中間点として機能します。
一般的な理由は2つあります。
あなたはセキュリティのためにそれを使うことができます。メインテーブルに権限を付与せず、列または行へのアクセスを制限するビューを作成し、ビューを表示する権限をユーザーに付与します。
便利に使えます。ビューで常に使用しているいくつかのテーブルを結合します。これにより、クエリの一貫性と簡単さが向上します。
これには複数の理由があります。すべての結合を行うのではなく、単にテーブル名を問い合わせるだけなので、一般的な結合問い合わせが簡単になることがあります。
もう1つの理由は、データを異なるユーザーに制限することです。だから例えば：
表1：列 - USER_ID; USERNAME; SSN
管理者ユーザーは実際のテーブルに特権を持つことができますが、SSNを言うためにアクセスする必要がないユーザーは、次のようにビューを作成します。
表1からユーザー名をSELECTとして選択user_id、username;
その後、テーブルではなくビューにアクセスできるように権限を与えます。
特定のデータに焦点を合わせるビューを使用すると、ユーザーは自分が関心を持つ特定のデータと、自分が担当する特定のタスクに集中することができます。不要なデータはビューから除外することができます。ユーザーはビューで定義されているデータのみを参照でき、基になるテーブルのデータは参照できないため、これによってデータのセキュリティも強化されます。セキュリティ上の目的でビューを使用する方法の詳細については、「セキュリティメカニズムとしてのビューの使用」を参照してください。
データ操作を簡単にするビューを使用すると、ユーザーがデータを操作する方法を簡単にすることができます。頻繁に使用される結合、射影、UNIONクエリ、およびSELECTクエリをビューとして定義すると、そのデータに対して追加の操作を実行するたびにユーザーがすべての条件と資格を指定する必要がなくなります。たとえば、レポート目的で使用され、テーブルのグループからデータを取得するためにサブクエリ、外部結合、集計を実行する複雑なクエリをビューとして作成できます。基になるクエリは、レポートが生成されるたびに作成または送信する必要がないため、ビューによってデータへのアクセスが簡単になります。代わりにビューが照会されます。データ操作の詳細については。
論理的にパラメータ化されたビュー、またはWHERE句の検索条件にパラメータを持つビューとして機能するインラインのユーザー定義関数を作成することもできます。詳細については、インラインユーザ定義関数を参照してください。
データをカスタマイズするビューを使用すると、同じデータを同時に使用している場合でも、異なるユーザーが異なる方法でデータを見ることができます。これは、さまざまな興味やスキルレベルを持つユーザーが同じデータベースを共有している場合に特に有利です。たとえば、アカウントマネージャが扱う顧客のデータのみを取得するビューを作成できます。ビューを使用するアカウントマネージャのログインIDに基づいて、ビューはどのデータを取得するかを決定できます。
データをエクスポートおよびインポートするビューを使用して、他のアプリケーションにデータをエクスポートできます。たとえば、pubsデータベース内の店舗と売上表を使用して、Microsoft®Excelを使用して売上データを分析することができます。これを行うには、店舗と売上表に基づいてビューを作成します。その後、bcpユーティリティを使用して、ビューで定義されているデータをエクスポートできます。 INSERT文を使用して行をビューに挿入できる場合は、bcpユーティリティまたはBULK INSERT文を使用して、データファイルから特定のビューにデータをインポートすることもできます。データをビューにコピーする際の制限について詳しくは、INSERTを参照してください。 bcpユーティリティとBULK INSERT文を使用してビューとの間でデータをコピーする方法の詳細については、ビューへのコピーまたはビューからのコピーを参照してください。
パーティション化されたデータを結合するにはTransact-SQLのUNION集合演算子をビュー内で使用して、別々のテーブルからの2つ以上のクエリの結果を単一のテーブルに結合できます。結果セットこれは、パーティション・ビューと呼ばれる単一の表としてユーザーに表示されます。たとえば、あるテーブルにWashingtonの売上データが含まれ、別のテーブルにCaliforniaの売上データが含まれる場合、それらのテーブルのUNIONからビューを作成できます。ビューは、両方の地域の売上データを表します。パーティションビューを使用するには、各テーブルに追加できるデータの範囲を決定するための制約を指定して、同一のテーブルをいくつか作成します。その後、これらの実表を使用してビューが作成されます。ビューが照会されると、SQL Serverはどのテーブルがクエリの影響を受けているかを自動的に判断し、それらのテーブルのみを参照します。たとえば、ワシントン州の売上データのみが必要であるとクエリで指定されている場合、SQL Serverはワシントンの売上データを含むテーブルのみを読み取ります。他のテーブルはアクセスされません。
パーティションビューは、同じデータベース内のテーブルだけでなく、リモートサーバーなどの複数の異種ソースからのデータに基づくことができます。たとえば、それぞれが組織の異なる地域のデータを格納している異なるリモートサーバーからのデータを組み合わせるには、各データソースからデータを取得する分散クエリを作成し、それらの分散クエリに基づいてビューを作成します。どのクエリでも、クエリによって要求されたデータを含むリモートサーバー上のテーブルからのデータのみが読み取られます。ビュー内の分散照会によって参照される他のサーバーはアクセスされません。
複数のテーブルまたは複数のサーバーにまたがってデータを分割すると、スキャンするデータが少なくなるため、データの一部にのみアクセスするクエリの実行速度が速くなります。テーブルが異なるサーバー上、または複数のプロセッサを搭載したコンピュータ上にある場合は、クエリに含まれる各テーブルを同時にスキャンしてクエリのパフォーマンスを向上させることもできます。さらに、インデックスの再構築やテーブルのバックアップなどのメンテナンスタスクをより迅速に実行できます。パーティションビューを使用すると、データは単一のテーブルとして表示され、正しい基になるテーブルを手動で参照しなくてもクエリを実行できます。
パーティション化ビューは、次のいずれかの条件が満たされると更新可能です。INSTEAD OFトリガーが、INSERT、UPDATE、およびDELETEステートメントをサポートするロジックを使用してビューに定義されている。
ビューとINSERT、UPDATE、およびDELETEステートメントはどちらも、更新可能なパーティションビューに定義されている規則に従います。詳細については、「分割ビューの作成」を参照してください。
https://technet.Microsoft.com/ja-jp/library/aa214282（v = sql.80）.aspx＃sql：join
一般的に、ビューを使いやすくし、複数のテーブルに格納されているエンティティから詳細情報を取得し（コードを読みやすくするために結合を排除）、複数のデータベースでデータを共有したり、挿入を読みやすくします。
これは、ユーザーがテーブル内で更新できる列を制限するためにパーミッションと一緒にビューを使用する方法です。
/* This creates the view, limiting user to only 2 columns from MyTestTable */
CREATE VIEW dbo.myTESTview
WITH SCHEMABINDING AS
SELECT ID, Quantity FROM dbo.MyTestTable;
/* This uses the view to execute an update on the table MyTestTable */
UPDATE dbo.myTESTview
SET Quantity = 7
WHERE ID = 1
レガシーデータベースでレポートを作成するときには、ビューが悪影響を及ぼす可能性があります。特に、不可解な5文字の名前（そのうち2つは一般的な接頭辞です）や、当時は当然のことと思われる省略形でいっぱいの列名の代わりに、賢いテーブル名を使用することができます。
ビューについての1つの奇妙なことは、それらがテーブルとしてMicrosoft Accessによって見られるということです：ODBCを使用してMicrosoft AccessフロントエンドをSQLデータベースに接続するとき、あなたは利用可能なテーブルのリストにテーブルとビューを見る。そのため、MS Accessで複雑なレポートを作成している場合は、SQLサーバーに参加とクエリを実行させ、生活を大幅に簡素化することができます。 MS Excelでクエリを作成するための同上。
私は自分のデータに対して呼び出すことができるメソッドとしてストアドプロシージャをもっと見ていますが、私にとってビューはクエリやストアドプロシージャを作成することができるベースデータの合成バージョンを作成するためのメカニズムを提供します。単純化または集約が理にかなっているときにビューを作成します。非常に具体的なサービスを提供したい場合は、ストアドプロシージャを作成します。
メインテーブル（Productsテーブルなど）と参照テーブル（ProductTypeやProductDescriptionByLanguageなど）の間のすべての関係をマップするxxxを作成しています。これは私が製品を検索することを可能にするビューを作成し、そのすべての詳細が外部キーからその説明に変換されます。それから、ORMを使ってオブジェクトを作成し、グリッドやコンボボックスなどを簡単に構築することができます。
テーブルのスナップショットを見たいとき、および/またはview（読み取り専用）
これはあなたの質問に正確には答えませんが、言及する価値があると思いますマテリアライズドビュー。私の経験はほとんど Oracle ですが、おそらくSQL-Serverはかなり似ています。
XMLパフォーマンスの問題に対処するために、私たちのアーキテクチャでも似たようなものを使いました。当社のシステムは、XMLとして1行に格納された大量のデータで設計されており、アプリケーションはその中の特定の値を照会する必要があるかもしれません。大量のXMLTypeを処理し、多数の行にわたってXPathを実行することはパフォーマンスに大きな影響を与えるため、基本表が変更されたときはいつでも、リレーショナル表に目的のXMLノードを抽出するためにマテリアライズドビューの形式を使用します。これは、要求に応じてクエリを実行する標準的なビューとは対照的に、ある時点でのクエリの物理的なスナップショットを効果的に提供します。
本番データベースには10個程度のビューしかありません。私はいつも使っているカラムにいくつか使っています。私が使用する1つのセットは7つのテーブルから来ています。いくつかは外部結合を持っています。書き直すのではなく、絶えずselectでそのビューを呼び出して1つまたは2つの結合を行う必要があります。私にとっては、それは単なる時間節約です。
クエリを実行しているときだけ、ストアドプロシージャでビューを使用するのが好きです。また、ビューはセキュリティを単純化し、複数のテーブルへの挿入/更新を容易にするために使用したり、データのスナップショット/マテリアライズに使用することができます（長時間実行されるクエリを実行し、結果をキャッシュに保持します）。
実時間で正確に保つ必要のない、実行時間の長いクエリにはマテリアライズドビューを使用しました。
ビューはまた、非常に複雑な構成とテーブルを、照会しやすい管理可能なチャンクに分割します。データベースでは、テーブル管理システム全体が1つの大きなテーブルからのビューに分割されています。
私は最初の考えだ。クエリの複雑さを隠すそれはビューに非常に適しています。データベーステーブルを正規化するときの増加方法。テーブルの数が増加したときのデータのフェッチ方法は非常に困難です。
セキュリティのために各ユーザーに、そのユーザーまたはユーザーのグループが表示を許可されている特定のデータを含む少数のビューのみを介してデータベースにアクセスする許可を与え、他のデータへのユーザーアクセスを制限します。
クエリと構造の単純さ：ビューは複数のテーブルからデータを引き出して単一のテーブルを表示することができ、情報を単純化し、ビューに対して複数テーブルクエリを単一テーブルクエリに変換します。データベース構造の表示。特定のユーザーまたはユーザーグループに固有の一連の仮想テーブルとしてデータベースを表示します。
一貫性のあるデータベース構造を作成するため：基礎となるソーステーブルが変更されても、ビューはデータベース構造の一貫性のある変更されていないイメージを表示します。
テーブル内のすべての行/列へのアクセスを制限または制限するためのビューを作成します。所有者が特定または限定された行/列のみを共有する必要がある場合は、それらの列でビューを作成します。
データベーススキーマをリファクタリングすると考えてください。