テーブルではなくビューを使用する場合

ビューを実際のテーブルで実際に使用する必要があるのはいつですか？これによりどのような利益が期待できますか？

全体として、テーブルよりもビューを使用する利点は何ですか？そもそもビューがどう見えるかでテーブルをデザインすべきではないでしょうか？

ああ、あなたが考慮する必要がある多くの違いがあります

選択のためのビュー：

1. ビューはテーブルの抽象化を提供します。基になるスキーマを変更せずに、ビューでフィールドを簡単に追加/削除できます
2. ビューは複雑な結合を簡単にモデル化できます。
3. ビューはデータベース固有のものを非表示にすることができます。たとえば、OracleのSYS_CONTEXT関数などを使用していくつかのチェックを行う必要がある場合
4. 実際のテーブルではなく、ビューで直接GRANTSを簡単に管理できます。特定のユーザーがビューにしかアクセスできない場合は、管理が簡単になります。
5. ビューは、下位​​互換性を維持するのに役立ちます。基礎となるスキーマを変更できますが、ビューはそれらの事実を特定のクライアントから隠すことができます。

挿入/更新のビュー：

1. Oracleの「WITH CHECK OPTION」句などの機能をビューで直接使用して、ビューのセキュリティ問題を処理できます。

欠点

1. リレーション（主キー、外部キー）に関する情報を失う
2. ビューはその下にある結合を隠しているため、ビューを挿入/更新できるかどうかは明らかではありません

ビューは次のことができます。

• 複雑なテーブル構造を簡素化する
• 機密データをフィルタリングし、より簡単な方法で権限を割り当てることができるようにすることで、セキュリティモデルを簡素化します
• 出力構造を変更せずにロジックと動作を変更できます（出力は同じままですが、基になるSELECTが大幅に変更される可能性があります）
• パフォーマンスを向上させる（SQL Serverインデックス付きビュー）
• 他の方法では収集が困難な可能性があるビューを使用して、特定のクエリ最適化を提供する

また、ビューと一致するようにテーブルを設計しないでください。基本モデルは、データの効率的な保存と取得に関係する必要があります。ビューは、その複雑さを抽象化できるようにすることにより、効率的な正規化モデルから生じる複雑さを軽減するツールの一部です。

また、「テーブルよりもビューを使用する利点は何ですか？」と尋ねることは、優れた比較ではありません。テーブルなしで行くことはできませんが、ビューなしで行うことができます。それらはそれぞれ非常に異なる理由で存在します。テーブルは具体的なモデルであり、ビューは抽象化されたビューです。

複雑なロジックが毎回行われるようにする必要がある場合、ビューは許容されます。たとえば、すべての財務報告に必要な生データを作成するビューがあります。すべてのレポートでこのビューを使用することで、1つのレポートで1つの結合セットを使用し、別の結合で別の結果を生成するレポートを使用するのではなく、全員が同じデータセットから作業します。

ユーザーを特定のデータのサブセットに制限する場合は、ビューを使用できます。たとえば、レコードを削除せず、現在のレコードをアクティブとしてマークし、古いバージョンを非アクティブとしてマークするだけの場合、ビューを使用してアクティブなレコードのみを選択します。これにより、クエリにwhere句を入れるのを忘れて、悪い結果が出るのを防ぐことができます。

ビューを使用して、ユーザーがレコードのセットにのみアクセスできるようにすることができます。たとえば、特定のクライアントのテーブルのビューがあり、テーブルに対するセキュリティ権限がない場合、そのクライアントのユーザーはデータしか見ることができない可能性があります。そのクライアントのために。

ビューは、データベースをリファクタリングするときに非常に役立ちます。

ビューを使用してビューを呼び出す場合、ビューは受け入れられません。これにより、（少なくともSQL Serverでは）パフォーマンスが著しく低下する可能性があります。誰かがそのようにデータベースを抽象化することを選択し、パフォーマンスが恐ろしく、タイムアウトが頻繁に発生したため、数百万ドルのクライアントをほぼ失った。パフォーマンスの問題は完全に私たちのせいだったので、クライアントではなく修正の費用も支払わなければなりませんでした。ビューがビューを呼び出すとき、それらは基礎となるビューを完全に生成する必要があります。ユーザーが最終的に必要とする3つを確認するために、ビューと呼ばれるビューと呼ばれるビューと、何百万ものレコードが生成される場所で、これを確認しました。これらのビューの1つがレコードの単純なカウント（*）を行うのに8分かかったことを覚えています。ビューを呼び出すビューは非常に貧弱なアイデアです。

ビューは、通常、同じテーブルのフィールドしか更新できないため（これもSQL Serverであり、他のデータベースは異なる場合があります）、レコードの更新に使用することはよくありません。その場合は、とにかく直接テーブルを更新して、どのフィールドが利用可能かを把握する方が理にかなっています。

ビューは、複数のテーブルから選択する必要がある場合、またはテーブルのサブセットを取得するだけの場合に便利です。

データベースが適切に正規化されるように（最小の重複）テーブルを設計する必要があります。これにより、クエリが多少難しくなる場合があります。

ビューは少し分離されており、格納されているものとは異なる方法でテーブルのデータを表示できます。

一般的な方法は、ビューで結合を非表示にして、より非正規化されたデータモデルをユーザーに提示することです。その他の用途には、セキュリティ（特定の列や行を非表示にするなど）またはパフォーマンス（マテリアライズドビューの場合）が含まれます。

ビューを考慮せずにテーブルを設計する必要があります。
結合と条件の保存とは別に、ビューにはパフォーマンス上の利点があります。SQLServerはビューで実行プランを計算して保存するため、「オンザフライ」のSQLステートメントよりも高速になります。
ビューを使用すると、フィールドレベルでのユーザーアクセスに関する作業も容易になります。

まず、名前が示すように、ビューは不変です。これは、ビューがDBに保存されたクエリから作成された仮想テーブルに他ならないためです。このため、ビューにはいくつかの特性があります。

• データのサブセットのみを表示できます
• 複数のテーブルを単一のビューに結合できます
• ビューのデータを集計できます（カウントを選択）
• ビューは実際にはデータを保持しません。基礎となるテーブルの仮想集約であるため、テーブルスペースは必要ありません。

そのため、テーブルよりもビューの方が適しているという膨大な数のユースケースがあります。Webサイトでアクティブユーザーのみを表示することを考えてください。実際にDBにあるデータのサブセット（アクティブユーザーと非アクティブユーザー）のみを操作するため、ビューの方が良いでしょう。

この記事をチェックしてください

これがお役に立てば幸いです。

ウィキペディアによると、

ビューには、テーブルよりも多くの利点があります。

• ビューは、テーブルに含まれるデータのサブセットを表すことができます。

• ビューは、基になるテーブルの外部への露出の程度を制限する可能性があります。特定のユーザーは、ビューをクエリする権限を持っている可能性がありますが、ベーステーブルの残りの部分へのアクセスは拒否されます。

• ビューは、複数のテーブルを結合して単一の仮想テーブルに簡略化できます。

• ビューは、データベースエンジンがデータ（合計、平均など）を集計し、計算結果をデータの一部として表示する、集計テーブルとして機能できます。

• ビューはデータの複雑さを隠すことができます。たとえば、ビューはSales2000またはSales2001として表示され、実際の基になるテーブルを透過的に分割できます。

• ビューの保存に必要なスペースはほとんどありません。データベースにはビューの定義のみが含まれ、ビューが提供するすべてのデータのコピーは含まれません。

• 使用するSQLエンジンに応じて、ビューは追加のセキュリティを提供できます。