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