ビューは何に適していますか？
私はRDBMSでどのビューが使用されているかについての一般的な考えを得ようとしているだけです。つまり、私はビューとは何か、どのようにビューを作成するかを知っています。私は過去にそれらを何に使用したかも知っています。
しかし、ビューが何に役立つのか、ビューが何に役立つべきでないのかを徹底的に理解したいと思います。すなわち：
- ビューは何に役立ちますか？
- ビューを使用するべきではないときに、ビューを使用したくなるような状況はありますか？
- テーブル値関数などの代わりにビューを使用するのはなぜですか？
- 一見しただけではわからない、ビューが役立つかもしれない状況はありますか？
（そして、記録のために、これらの質問のいくつかは意図的にナイーブです。これは部分的に概念チェックです。）
1）ビューは何に役立ちますか？
IOPO 1か所のみ
•データ自体を考慮しても、結合されたテーブルを参照するクエリを考慮しても、ビューを利用することで、不要な冗長性を回避できます。
•ビューは、テーブルへの直接アクセスを防止する抽象化レイヤーも提供します（物理的な依存関係を参照する結果として生じる手錠）。実際、それは いい練習1 以下のようなビューを含む、（ビューおよびテーブル値関数を使用した）基礎となるデータへの抽象化されたアクセスのみを提供CREATE VIEW AS
SELECT * FROM tblData
1私はそのアドバイスに「私が言うようにではなく、私がするようにではない」がかなりあることを認めています;）
2）ビューを使用するべきではないのに、ビューを使用したくなるような状況はありますか？
以前はビュー結合のパフォーマンスが問題でした（SQL 2000など）。私は専門家ではありませんが、しばらく心配していません。 （私が現在ビュー結合を使用している場所を考えることもできません。）
ビューが過剰になるもう1つの状況は、ビューが1つの呼び出し場所からのみ参照され、代わりに派生テーブルを使用できる場合です。匿名型が一度だけ使用/参照される場合は、.NETのクラスよりも匿名型の方が望ましいです。
•http://msdn.Microsoft.com/en-us/library/ms177634.aspxの派生テーブルの説明を参照してください
3）テーブル値関数などの代わりにビューを使用するのはなぜですか？
（パフォーマンス上の理由は別として）テーブル値関数は、パラメーター化されたビューと機能的に同等です。実際、一般的な単純なテーブル値関数の使用例は、単一のオブジェクトの既存のビューにWHERE句フィルターを追加することです。
4）一見しただけではわからない、ビューが役立つかもしれない状況はありますか？
頭のてっぺんの見かけ以外の使い方は考えられません。 （もしできれば、それが明らかになると思います;）
ある意味では、ビューはインターフェースのようなものです。基本となるテーブル構造を自由に変更できますが、ビューを使用すると、コードを変更する必要がなくなります。
ビューは、ライターを報告するために簡単なものを提供する良い方法です。ビジネスユーザーがCrystal Reportsなどのデータにアクセスしたい場合は、アカウント内でデータを簡略化するビューを提供できます。データを非正規化することもできます。
ビューはセキュリティを提供するために使用できます（つまり、ユーザーはテーブル内の特定の列にのみアクセスするビューにアクセスできます）、ビューは更新や挿入などに追加のセキュリティを提供できます。ビューは列名にエイリアスを付ける方法も提供します（ sp's）ですが、ビューは実際のテーブルからの分離です。
ある意味では、ビューは非正規化されます。より意味のある方法でデータを提供するために、非正規化が必要になる場合があります。これは、多くのアプリケーションがオブジェクトのドメインモデリングによってとにかく行うことです。これらは、ビジネスの視点により近い方法でデータを表示するのに役立ちます。
ビューはデータベースの複雑さを隠します。これらは多くの理由で優れており、多くの状況で役立ちますが、独自のクエリとレポートを作成することを許可されているユーザーがいる場合は、それらを安全な手段として使用して、不適切に設計されたものを送信しないようにすることができますデータベースサーバーを停止させる厄介なデカルト結合を使用したクエリ。
他の人が述べたことに加えて、ビューはアプリケーションからより複雑なSQLクエリを削除するのにも役立ちます。
例として、アプリケーションでは次のようにします：
sql = "select a、b from table1 union select a、b from table2";
あなたはそれをビューに抽象化することができます：
ビューunion_table1_table2_vを作成
テーブル1からa、bを選択します
連合
テーブル2からa、bを選択します
そして、アプリのコードでは、単に次のようにします：
sql = "selection a、b from union_table1_table2_v";
また、データ構造が変更された場合でも、アプリのコードを変更し、再コンパイルして再デプロイする必要はありません。データベースのビューを変更するだけです。
OPは、ビューを使用したくなるかもしれない状況があるかどうか尋ねましたが、それは適切ではありません。
ビューを使用したくないのは、複雑な結合の代わりです。つまり、問題を小さな部分に分割するという手続き型プログラミングの習慣によって、1つの大きな結合ではなく、いくつかのビューを結合するようにさせないでください。これを行うと、1つの大きなクエリではなく、基本的に複数の個別のクエリが実行されるため、データベースエンジンの効率が低下します。
たとえば、テーブルA、B、C、Dを結合する必要があるとします。テーブルAとBからビューを作成し、CとDからビューを作成してから、2つのビューを結合したくなるかもしれません。 1つのクエリでA、B、C、Dを結合する方がはるかに優れています。
ビューはデータを一元化または統合できます。私がいるところには、いくつかの異なるリンクサーバー上にいくつかの異なるデータベースがあります。各データベースは、異なるアプリケーションのデータを保持します。これらのデータベースのいくつかは、さまざまなアプリケーションに関連する情報を保持しています。このような状況で実行するのは、そのアプリケーションのデータベースに、データが実際に格納されているデータベースからデータをプルするだけのビューを作成することです。これにより、作成するクエリが異なるデータベースにまたがっているように見えなくなります。
これまでの応答は正しいです。ビューは、セキュリティ、非正規化（間違った場合はその道のりにかなりの痛みがあります）、データモデルの抽象化などを提供するのに適しています。
さらに、ビューは通常、ビジネスロジックを実装するために使用されます（失効したユーザーとは、過去40日間ログインしていないユーザーのことです）。
ビューは、SQLスクリプトで繰り返される複雑なJOINステートメントの多くを保存します。複雑なJOINをビューにカプセル化して、必要なときにSELECTステートメントで呼び出すことができます。これは、すべてのクエリで結合ステートメントを記述するよりも、便利で簡単な場合があります。
ビューは、保存された名前付きのSELECTステートメントです。ライブラリ関数のようなビューを考えてください。
いくつかのUNIONを含む非常に長いSELECTを覚えています。各UNIONには、SELECTによってオンザフライで作成された価格表への結合が含まれていましたが、それ自体はかなり長く、理解が困難でした。価格表を作成するという見方があれば良かったと思います。これにより、SELECT全体が約半分に短縮されます。
DBがビューを1回評価するか、inが呼び出されるたびに1回評価されるかわかりません。誰か知ってる？前者の場合、ビューを使用するとパフォーマンスが向上します。
レポート用のビューの使用を強調したかったのです。多くの場合、特にデータの編集と挿入（OLTPの使用）のパフォーマンスを向上させるためのデータベーステーブルの正規化と、レポートおよび分析（OLAPの使用）のクエリのテーブル結合の数を減らすための非正規化の間には矛盾があります。必要に応じて、OLTPデータエントリには最適なパフォーマンスが必要であるため、通常は成功します。ビューを作成すると、最適なレポートパフォーマンスを得るために、両方のクラスのユーザー（データエントリとレポートビューア）を満たすことができます。
[my_interface]！= [user_interface]が必要なときはいつでも。
例：
表A：
- id
- 情報
表Aのビュー：
- 顧客情報
これは、顧客に対してIDを非表示にし、情報の名前をより詳細な名前に一度に変更する方法です。
ビューは主キーIDの基礎となるインデックスを使用するため、パフォーマンスの低下は見られず、選択クエリの抽象化が向上するだけです。