SQL Server では、ビューにインデックスを作成できることを知っています。その後、ビューは基になるテーブルからデータを保存します。次に、ビューを照会できます。しかし、なぜテーブルの代わりにビューを使用する必要があるのでしょうか?
5 に答える
ビューを使用してクエリを簡素化することができます。私たちのプロジェクトでは、インターフェイス、特に「レポート インターフェイス」にビューを使用することについてコンセンサスが得られています。
あなたが顧客テーブルを持っていて、マネージャーが顧客の名前と口座残高 (または何でも) を記載したレポートを毎朝必要としていると想像してください。テーブルに対してレポートをコーディングすると、レポートとテーブルの間に強力なリンクが作成され、後で変更することが難しくなります。
一方、レポートがビューにヒットした場合は、データベースを自由にひねることができます。ビューが同じである限り、レポートは機能します。マネージャーは満足し、データベースを自由に試すことができます。クライアントのメタデータをメインのクライアント テーブルから分離したいですか? 頑張って、ビューで 2 つのテーブルを結合してください。クライアントのカート情報を非正規化したいですか? 問題ありません。ビューは適応できます...
正直に言うと、これはプログラマーとしての私の見解ですが、他の用途は db グルによって確実に発見されるでしょう :)
基本的に、ビューを使用します。
- 多くのテーブルで同じ複雑なクエリを複数回使用する場合。
- 新しいシステムが古いテーブルデータを読み取る必要があるが、認識されたスキーマの変更を監視しない場合。
インデックス付きビューは、冗長性を増やさずに、より具体的なインデックスを作成することでパフォーマンスを向上させることができます。
インデックス付きビューを使用する利点の 1 つは、列が異なるテーブルにある 2 つ以上の列の結果を並べ替える場合です。つまり、table1.column1、table2.column2 でソートされた table1 と table2 の結果であるビューがあります。次に、列1、列2にインデックスを作成して、そのクエリを最適化できます
テーブルは、データが物理的に格納される場所です。
ビューは、テーブルのグループを使いやすくするために、テーブルを要約またはグループ化する場所です。
インデックス付きビューを使用すると、クエリでビューを使用できます。ビューには既にデータが含まれているため、基になるテーブルからデータを取得する必要がなく、パフォーマンスが向上します。
データベースを非正規化せずにテーブルだけで同じ結果を達成することはできず、他の問題が発生する可能性があります。
ビューは、名前が付けられ、データベースに格納された単純な SELECT ステートメントです。ビューの主な利点は、ビューが作成されると、作成する他の SELECT ステートメントのテーブルのように機能することです。
ビューの select ステートメントは、テーブル、他のビュー、および関数を参照できます。
ビュー (インデックス付きビュー) にインデックスを作成して、パフォーマンスを向上させることができます。インデックス付きビューは自己更新型であり、基になるテーブルへの変更が即座に反映されます。
インデックス付きビューが 1 つのテーブルから列のみを選択する場合、そのテーブルにインデックスを配置して、そのテーブルを直接クエリすることもできます。ビューはデータベースのオーバーヘッドを引き起こすだけです。ただし、SELECT ステートメントが結合などで複数のテーブルをカバーしている場合は、ビューにインデックスを配置することでパフォーマンスを向上させることができます。