回答:
ビューにはいくつかの利点があります。
1.ビューは複雑さを隠すことができる
複数のテーブルを結合する必要があるクエリがある場合、または複雑なロジックや計算がある場合は、そのロジックをすべてビューにコーディングしてから、テーブルと同じようにビューから選択できます。
2.ビューはセキュリティメカニズムとして使用できます。
ビューは、1つまたは複数のテーブルから特定の列や行を選択でき、基礎となるテーブルの代わりにビューに設定された権限を選択できます。これにより、ユーザーが表示する必要のあるデータのみを表示できます。
3.ビューはレガシーコードのサポートを簡素化できます
多くのコードが壊れるテーブルをリファクタリングする必要がある場合は、テーブルを同じ名前のビューに置き換えることができます。ビューは元のテーブルとまったく同じスキーマを提供しますが、実際のスキーマは変更されています。これにより、テーブルを参照するレガシーコードが破損することがなくなり、レガシーコードを自由に変更できます。
これらは、ビューがどのように役立つかを示す多くの例のほんの一部です。
特に、セキュリティに使用できます。「顧客」テーブルがある場合は、すべての営業担当者に、名前、住所、郵便番号などのフィールドへのアクセスを許可し、credit_card_numberは許可しないようにすることができます。アクセスが必要な列のみを含むビューを作成して、ビューへのアクセスを許可できます。
Select name, address, zipcode from customer代わりに目的を果たしませんcreating a viewか？
select * from customerユーザーはすべてにアクセスできるように実行できます。テーブルではなくビューへのアクセスを許可すると、ビューにないフィールドにはアクセスできません。
ビューはクエリをカプセル化したものです。ビューに変換されたクエリは複雑になる傾向があるため、再利用するためにビューとして保存すると効果的です。
私は通常、レポート目的で頻繁に使用されるデータを非正規化または集約するためのビューを作成します。
編集
詳細を説明すると、エンティティの一部が個人、会社、役割、所有者の種類、注文、注文の詳細、住所、電話であるデータベースがある場合、personテーブルには従業員と連絡先の両方、および住所と電話テーブルには、個人と企業の両方の電話番号が格納され、開発チームは、従業員ごとの売上、顧客ごとの売上、または地域ごとの売上、月ごとの売上などのレポートの生成（または開発者以外がレポートデータにアクセスできるようにする）を課されました、州ごとの顧客などデータベースエンティティ間の関係を非正規化した一連のビューを作成し、現実のエンティティのより統合されたビュー（しゃれが意図されていない）を利用できるようにします。利点には次のようなものがあります。
いくつかの理由：複雑な結合がある場合は、ビューを用意して、すべてのアクセスで常に正しい結合が得られ、開発者が必要とするすべてのテーブルを覚えておく必要がないようにすることが最善の場合があります。通常、これはすべての財務レポートが同じデータセットに基づいていることが非常に重要である財務アプリケーションの場合です。
表示できるレコードを制限したいユーザーがいる場合は、ビューを使用して、基になるテーブルではなく、ビューへのアクセスのみを許可してから、ビューにクエリを実行できます。
Crystalレポートは、ストアドプロシージャにビューを使用することを好むようです。そのため、多くのレポート作成を行う人は、多くのビューを使用する傾向があります。
ビューは、データベースをリファクタリングするときにも非常に役立ちます。多くの場合、ビューを作成することにより、変更を非表示にして、古いコードが変更を認識できないようにすることができます。データベースのリファクタリングを読んで、これがリファクタリングの非常に強力な方法であることを確認してください。
ストアドプロシージャに対するビューの主な利点の1つは、テーブルを使用するのと同じようにビューを使用できることです。つまり、FROMクエリの句で直接ビューを参照できます。例えば、SELECT * FROM dbo.name_of_view。
他のほぼすべての方法で、ストアドプロシージャはより強力です。あなたには、パラメータを渡すことができout、あなたが行うことができます、あなたが効果的に一度に複数の値を返すことができるようにパラメータSELECT、INSERT、UPDATE、およびDELETE操作、などなど
FROM節内からクエリを実行するビューの機能が必要であるが、パラメーターを渡すこともできるようにしたい場合は、それを行う方法もあります。これはテーブル値関数と呼ばれます。
このトピックに関するかなり役立つ記事を次に示します。
編集：ところで、この種の問題は、ビューがテーブル値関数よりも優れているという疑問を引き起こしますか？私にはそれに対する良い答えはありませんが、ビューを作成するためのT-SQL構文はテーブル値関数よりも簡単で、データベースのユーザーはビューに慣れている可能性があることに注意します。
ORMとテーブルの間の優れた「中間者」として機能できます。
例：
構造を変更する必要があるPersonテーブルがあったため、SomeColumn列は別のテーブルに移動され、1対多の関係になります。
ただし、Personに関するシステムの大部分は、SomeColumnを単一のものとして使用し、多くのものは使用していません。ビューを使用してすべてのSomeColumnsをまとめ、ビューに配置しましたが、うまくいきました。
これはデータレイヤーが変更されたために機能しましたが、ビジネス要件は根本的に変更されていなかったため、ビジネスオブジェクトを変更する必要はありませんでした。ビジネスオブジェクトを変更する必要がある場合、これは実行可能な解決策ではなかったと思いますが、ビューは間違いなく優れた中点として機能します。
特定のデータ ビューに焦点を合わせると、ユーザーは、関心のある特定のデータと、自分が担当する特定のタスクに焦点を合わせることができます。不要なデータはビューから除外できます。これにより、ユーザーはビューで定義されているデータのみを表示でき、基になるテーブルのデータは表示できないため、データのセキュリティも向上します。セキュリティ目的でのビューの使用の詳細については、「セキュリティメカニズムとしてのビューの使用」を参照してください。
データ操作 を簡略化するビューは、ユーザーがデータを操作する方法を簡略化できます。頻繁に使用される結合、プロジェクション、UNIONクエリ、およびSELECTクエリをビューとして定義できるため、ユーザーはそのデータに対して追加の操作が実行されるたびにすべての条件と条件を指定する必要がありません。たとえば、レポートの目的で使用され、サブクエリ、外部結合、集計を実行してテーブルのグループからデータを取得する複雑なクエリは、ビューとして作成できます。レポートが生成されるたびに、基になるクエリを書き込んだり送信したりする必要がないため、ビューによってデータへのアクセスが簡素化されます。代わりにビューが照会されます。データの操作の詳細については。
パラメータ化されたビュー、またはWHERE句の検索条件にパラメータを持つビューとして論理的に動作するインラインのユーザー定義関数を作成することもできます。詳細については、「インラインユーザー定義関数」を参照してください。
データ ビューをカスタマイズすると、異なるユーザーが同じデータを同時に使用している場合でも、異なる方法でデータを表示できます。これは、さまざまな興味やスキルレベルを持つユーザーが同じデータベースを共有する場合に特に有利です。たとえば、アカウントマネージャーが取引する顧客のデータのみを取得するビューを作成できます。ビューは、ビューを使用するアカウントマネージャーのログインIDに基づいて、取得するデータを決定できます。
データをエクスポートおよびインポートするには、 ビューを使用してデータを他のアプリケーションにエクスポートできます。たとえば、Microsoft®Excelを使用して販売データを分析するために、pubsデータベースの店舗と販売テーブルを使用することができます。これを行うには、店舗と販売テーブルに基づいてビューを作成できます。次に、bcpユーティリティを使用して、ビューで定義されたデータをエクスポートできます。INSERTステートメントを使用してビューに行を挿入できる場合、bcpユーティリティまたはBULK INSERTステートメントを使用して、データファイルから特定のビューにデータをインポートすることもできます。データをビューにコピーする際の制限の詳細については、INSERTを参照してください。bcpユーティリティとBULK INSERTステートメントを使用してビューとの間でデータをコピーする方法の詳細については、「ビューとの間のコピー」を参照してください。
分割されたデータを組み合わせるには Transact-SQL UNIONセット演算子をビュー内で使用して、別々のテーブルからの2つ以上のクエリの結果を1つの結果セットに結合できます。これは、パーティションビューと呼ばれる単一のテーブルとしてユーザーに表示されます。たとえば、あるテーブルにワシントンの売上データが含まれ、別のテーブルにカリフォルニアの売上データが含まれている場合、それらのテーブルのUNIONからビューを作成できます。ビューは、両方の地域の売上データを表します。分割ビューを使用するには、いくつかの同一のテーブルを作成し、制約を指定して、各テーブルに追加できるデータの範囲を決定します。次に、これらのベーステーブルを使用してビューが作成されます。ビューがクエリされると、SQL Serverはクエリの影響を受けるテーブルを自動的に判別し、それらのテーブルのみを参照します。例えば、クエリでワシントン州の販売データのみが必要であると指定されている場合、SQL Serverはワシントンの販売データを含むテーブルのみを読み取ります。他のテーブルにはアクセスしません。
パーティションビューは、同じデータベース内のテーブルだけでなく、リモートサーバーなどの複数の異種ソースからのデータに基づくことができます。たとえば、組織の異なる地域のデータをそれぞれ格納する異なるリモートサーバーからのデータを組み合わせるには、各データソースからデータを取得する分散クエリを作成し、それらの分散クエリに基づいてビューを作成します。クエリは、クエリで要求されたデータを含むリモートサーバーのテーブルからデータのみを読み取ります。ビュー内の分散クエリによって参照される他のサーバーにはアクセスされません。
データを複数のテーブルまたは複数のサーバーに分割する場合、スキャンするデータが少ないため、データの一部にのみアクセスするクエリはより高速に実行できます。テーブルが異なるサーバー上にある場合、または複数のプロセッサを搭載したコンピューター上にある場合は、クエリに関係する各テーブルを並行してスキャンすることもできるため、クエリのパフォーマンスが向上します。さらに、インデックスの再構築やテーブルのバックアップなどのメンテナンスタスクをより迅速に実行できます。分割ビューを使用することで、データは単一のテーブルとして表示され、正しい基になるテーブルを手動で参照しなくても、そのようにクエリできます。
パーティションビューは、次のいずれかの条件が満たされた場合に更新可能です。INSTEAD OFトリガーが、INSERT、UPDATE、およびDELETEステートメントをサポートするロジックを使用してビューに定義されています。
ビューとINSERT、UPDATE、DELETEステートメントはどちらも、更新可能なパーティション分割ビューに対して定義されたルールに従います。詳細については、「分割ビューの作成」を参照してください。
https://technet.microsoft.com/en-us/library/aa214282(v=sql.80).aspx#sql:join
これを行う理由は複数あります。すべての結合を実行する代わりに、テーブル名をクエリするだけでよくある一般的な結合クエリが簡単になる場合があります。
別の理由は、データを別のユーザーに制限することです。たとえば：
表1：列-USER_ID; USERNAME; SSN
管理ユーザーは実際のテーブルで特権を持つことができますが、SSNを言うためのアクセス権を必要としないユーザーは、次のようにビューを作成します。
CREATE VIEW USERNAMES AS SELECT user_id、username from FROM Table1;
次に、テーブルではなくビューにアクセスする権限をユーザーに付与します。
ここでは、ビューとユーザーがテーブルで更新できる列を制限する権限を使用する方法を示します。
/* 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テーブルやビューのスナップショットを表示したいとき（読み取り専用で）
クエリを実行しているだけのときに、ストアドプロシージャのビューを使用するのが好きです。ビューは、セキュリティを簡素化し、複数のテーブルへの挿入/更新を容易にするために使用でき、データのスナップショット/実体化（長時間実行クエリを実行し、結果をキャッシュしておく）に使用できます。
リアルタイムで正確に保つ必要がないクエリを実行するためにマテリアライズドビューを使用しました。
これはあなたの質問に正確に答えるものではありませんが、マテリアライズドビューに言及する価値があると思いました。私の経験は主にOracleに関するものですが、おそらくSQL-Serverはかなり似ています。
私たちは、XMLパフォーマンスの問題に対処するために、アーキテクチャーで同様のものを使用しました。私たちのシステムは、行にXMLとして保存された多くのデータで設計されており、アプリケーションはその中の特定の値をクエリする必要があるかもしれません。多数のXMLTypeを処理し、多数の行にわたってXPathを実行すると、パフォーマンスに大きな影響があるため、実体化されたビューの形式を使用して、ベーステーブルが変更されるたびに目的のXMLノードをリレーショナルテーブルに抽出します。これは、クエリをオンデマンドで実行する標準ビューとは対照的に、ある時点でのクエリの物理的なスナップショットを効果的に提供します。
ビューの奇妙な点の1つは、ビューがMicrosoft Accessによってテーブルとして認識されることです。ODBCを使用してMicrosoft AccessフロントエンドをSQLデータベースに接続すると、使用可能なテーブルのリストにテーブルとビューが表示されます。したがって、MS Accessで複雑なレポートを準備している場合は、SQLサーバーに結合とクエリを実行させ、人生を大幅に簡略化できます。MS Excelでクエリを準備するための同上。
私の実稼働データベースには10ほどのビューしかありません。私はいつも使用する列にいくつか使用します。私が使用する1つのセットは7つのテーブルからのもので、一部は外部結合を持ち、常にビューを選択で呼び出して1つまたは2つの結合を作成するだけでよいという書き直しではありません。私にとっては、それは時間の節約に過ぎません。
テーブル内のすべての行/列へのアクセスを制限または制限するビューを作成します。所有者が特定または制限された行/列のみを共有する必要がある場合は、それらの列でビューを作成します。
セキュリティのために：ユーザーまたはユーザーのグループが表示を許可されている特定のデータを含む少数のビューを通じてのみ、データベースにアクセスするためのアクセス許可を各ユーザーに付与し、他のデータへのユーザーアクセスを制限します。
クエリと構造のシンプルさ：ビューは複数のテーブルからデータを引き出して単一のテーブルを表示できるため、情報が簡素化され、ビューの複数テーブルクエリが単一テーブルクエリに変換され、データベース構造の特定のビューが表示されます。特定のユーザーまたはユーザーグループに固有の仮想テーブルのセットとしてのデータベース。
一貫性のあるデータベース構造を作成する場合：基になるソーステーブルが変更されても、ビューはデータベース構造の一貫した変更されていないイメージを表示します。