データベース ビューが使用されるのはなぜですか?

Question

DB設計で「ビュー」を使用するのは正しい方法ですか、それともコード側で処理する必要がありますか?利点または欠点は何ですか?

Answer 1

ビューを使用する理由はいくつかあります。

• よりシンプルなインターフェースを提供します。十数のテーブルをクエリするのではなく、ビューをクエリするだけで、結合などをすべて実行できます。
• 変わらないインターフェースを提供する (またはそれより少ない頻度で) :
  • テーブルの構造を変更した場合でも、同じ結果を返すようにビューを変更できる場合があります。
  • つまり、アプリケーションのコードを変更する必要はありません。ビューを使用しており、テーブルに直接アクセスしていないため、引き続き機能します。
• テーブルの一部のフィールドへのインターフェイスのみを提供します
  • ユーザーが使用しないデータを表示する必要はありません
  • または、使用すべきではないデータにアクセスするため
• 一部のデータベース エンジンを使用する場合 （MS SQL Serverがそれをサポートしていると思います）, 、一部のタイプのビューにはインデックスを含めることができます
  • これはパフォーマンスにとって良いことです:複雑なクエリがある場合は、それをビューとして保存し、そのビューに必要なインデックスを定義します。

Answer 2

この場合のビューの 2 つの典型的なシナリオは次のとおりです。

• テーブル内の一部の列には、少数の人だけが閲覧できる機密データが含まれています。これらの列を除外するビューを作成し、そのビューをほとんどのユーザーに使用できます。
• 2 つ以上のテーブルを非正規化ビューに結合します。これはレポート目的には実用的ですが、データベースに格納するテーブルとしては意味がありません。

お役に立てれば。

Answer 3

場合によります。時々使いますが、それほど頻繁ではありません。ただし、これらは、レポート アプリケーションなどのエンド ユーザー (ツール) が使用するデータのデコードされたビューを説明するのに非常に役立ちます。このようにして、一部の技術的な詳細を隠した、頻繁に要求される情報の簡略版をエンド ユーザーに提供できます。

Answer 4

一部のデータベース システムでは、FROM 句内への SELECT ステートメントの埋め込みがサポートされていません。この機能をサポートしていないシステムを使用している場合は、多くの場合、内部の SELECT ステートメントをビューとして保存し、select ステートメントの代わりにビュー名を使用できます。

したがって、一部の DB 実装では欠落している可能性のある動作が提供されます。