テーブルの代わりにビューを使用する場合
ビューを実際のテーブルで実際に使用する必要があるのはいつですか？これによりどのような利益が期待できますか？
全体として、テーブルよりもビューを使用する利点は何ですか？そもそもビューがどのように見えるようにテーブルを設計すべきではないでしょうか？
考慮すべき多くの違いがあります
選択ビュー：
- ビューはテーブルを抽象化します。基礎となるスキーマを変更せずに、ビューでフィールドを簡単に追加/削除できます
- ビューは複雑な結合を簡単にモデル化できます。
- ビューは、データベース固有のものを隠すことができます。例えば。 OracleのSYS_CONTEXT関数または他の多くのことを使用していくつかのチェックを行う必要がある場合
- GRANTSは、実際のテーブルではなく、ビューで簡単に直接管理できます。特定のユーザーがビューにしかアクセスできないことがわかっている場合は、管理が簡単です。
- ビューは、後方互換性に役立ちます。基礎となるスキーマを変更できますが、ビューはそれらの事実を特定のクライアントから隠すことができます。
挿入/更新のビュー：
- Oracleの「WITH CHECK OPTION」句などの機能をビューで直接使用することにより、ビューのセキュリティ問題を処理できます。
欠点
- 関係に関する情報（主キー、外部キー）を失う
- ビューはその基礎となる結合を非表示にするため、ビューを挿入/更新できるかどうかは明らかではありません
ビューでできること：
- 複雑なテーブル構造を簡素化する
- 機密データをフィルタリングし、より簡単な方法で権限を割り当てることができるようにすることで、セキュリティモデルを簡素化します。
- 出力構造を変更せずにロジックと動作を変更できます（出力は同じままですが、基になるSELECTは大幅に変更される可能性があります）
- パフォーマンスの向上（SQL Serverのインデックス付きビュー）
- 他の方法では収集が困難な可能性があるビューを使用して、特定のクエリ最適化を提供します
ビューに一致するようにテーブルを設計するべきではありません。基本モデルは、データの効率的な保存と取得に関係する必要があります。ビューは、その複雑さを抽象化できるようにすることで、効率的な正規化モデルから生じる複雑さを緩和するツールの一部です。
また、「テーブルよりもビューを使用することの利点は何ですか？」テーブルなしでは行けませんが、ビューなしではできます。それらはそれぞれ非常に異なる理由で存在します。テーブルは具体的なモデルであり、ビューは抽象化されたビューです。
複雑なロジックが毎回実行されるようにする必要がある場合は、ビューを使用できます。たとえば、すべての財務レポートに必要な生データを作成するビューがあります。すべてのレポートでこのビューを使用することで、1つのレポートが1つの結合セットを使用し、別のレポートが異なる結果をもたらすレポートを使用するのを忘れるのではなく、全員が同じデータセットから作業します。
ユーザーをデータの特定のサブセットに制限する場合は、ビューを使用できます。たとえば、レコードを削除せず、現在のレコードをアクティブとしてマークし、古いバージョンを非アクティブとしてマークする場合、アクティブなレコードのみを選択するためにビューを使用する必要があります。これにより、人々がクエリにwhere句を入れるのを忘れて、悪い結果を得るのを防ぎます。
ビューを使用して、ユーザーが一連のレコードにのみアクセスできるようにすることができます。たとえば、特定のクライアントのテーブルのビューで、テーブルのセキュリティ権限がない場合、そのクライアントのユーザーはデータのみを表示できます。そのクライアントのために。
ビューは、データベースをリファクタリングするときに非常に役立ちます。
（少なくともSQL Serverで）恐ろしいパフォーマンスをもたらす可能性のあるビューを呼び出すためにビューを使用する場合、ビューは受け入れられません。誰かがデータベースをそのように抽象化することを選択したため、数百万ドルのクライアントをほぼ失いました。パフォーマンスは恐ろしく、タイムアウトが頻繁に発生しました。パフォーマンスの問題は完全に私たちのせいだったので、クライアントではなく、修正にもお金を払わなければなりませんでした。ビューがビューを呼び出すときは、基礎となるビューを完全に生成する必要があります。これは、ユーザーが最終的に必要とする3つを見るために、ビューがビューと呼ばれるビューと呼ばれるビューであり、非常に多くのレコードが生成される場所で見ました。これらのビューの1つは、レコードの単純なcount（*）を実行するのに8分かかったことを覚えています。ビューを呼び出すビューは非常に貧弱なアイデアです。
通常、ビューは同じテーブルのフィールドのみを更新できるため、レコードの更新に使用するのは悪い考えです（これもSQL Serverです。他のデータベースは異なる場合があります）。その場合は、とにかくテーブルを直接更新して、どのフィールドが利用可能かを知る方が賢明です。
一般的な方法は、ビューで結合を非表示にして、ユーザーにさらに非正規化されたデータモデルを表示することです。その他の用途には、セキュリティ（特定の列や行の非表示など）またはパフォーマンス（マテリアライズドビューの場合）が含まれます
ビューは、複数のテーブルから選択する必要がある場合や、テーブルのサブセットを取得する場合に便利です。
データベースが十分に正規化された（最小限の複製）になるようにテーブルを設計する必要があります。これにより、クエリが多少難しくなる可能性があります。
ビューは少し分離されているため、viewテーブル内のデータを格納されているものとは異なる方法で処理できます。
ビューを考慮せずにテーブルを設計する必要があります。
。
ビューは、フィールドレベルでのユーザーアクセスに関する作業を容易にする場合もあります。
まず、名前が示すとおり、ビューは不変です。これは、ビューがDBのストアドクエリから作成された仮想テーブルに他ならないためです。このため、ビューにはいくつかの特性があります。
- データのサブセットのみを表示できます
- 複数のテーブルを単一のビューに結合できます
- ビュー内のデータを集計できます（カウントを選択）
- ビューは実際にデータを保持してはいけません、それらは基礎となるテーブルの仮想集約であるため、テーブルスペースを必要としません
そのため、表よりもビューのほうが適しているユースケースは膨大です。Webサイトにアクティブなユーザーのみを表示することを考えてください。 DBに実際に存在するデータのサブセット（アクティブユーザーと非アクティブユーザー）のみを操作するため、ビューが優れている
これを確認してください 記事
これが役に立てば幸いです。
Wikipediaによると、
ビューには、テーブルよりも多くの利点があります。
- ビューは、テーブルに含まれるデータのサブセットを表すことができます。
ビューは、基礎となるテーブルの外部世界への露出度を制限することができます：特定のユーザーは、ビューへのアクセスを拒否しながら、ビューを照会する許可を持つことができます基本テーブルの残り。
ビューは、複数のテーブルを結合して単一の仮想テーブルに簡素化できます。
ビューは集計テーブルとして機能することができます。データベースエンジンはデータ（合計、平均など）を集計し、計算結果をデータの一部として表示します。
ビューはデータの複雑さを隠すことができます。たとえば、ビューはSales2000またはSales2001として表示され、実際の基礎となるテーブルを透過的に分割します。
ビューの保存に必要なスペースはほとんどありません;データベースにはビューの定義のみが含まれ、表示されるすべてのデータのコピーは含まれません。
ビューは、使用するSQLエンジンに応じて、追加のセキュリティを提供できます。