ビューを使用して、複数のテーブルから関連データを集約するカスタムの「テーブルビュー」(いわば)を作成できることを学びました。
私の質問は:ビューの利点は何ですか?具体的には、2つのテーブルがあるとします。
event | eid, typeid, name
eventtype | typeid, max_team_members
次に、ビューを作成します。
eventdetails | event.eid, event.name, eventtype.max_team_members
| where event.typeid=eventtype.typeid
event
のチームで許可されるメンバーの最大数が必要な場合は、次のことができます。
それぞれの方法での私の長所/短所は何ですか?
別のクエリ:テーブルイベントとイベントタイプのデータが更新された場合、ビューのデータの更新に関連するオーバーヘッドはありますか(結果のデータをキャッシュすることを考慮して)?
ビューは個別に保存されません。ビューをクエリすると、ビューはそのビューの定義に置き換えられます。したがって、テーブル内のデータへの変更は、ビューを介してすぐに表示されます。
前に指摘したセキュリティ機能に加えて:
その結合を実行するクエリを多数作成している場合は、そのSQLコードが除外されます。いくつかの場所で使用される関数でいくつかの操作を行うように、コードの読み取り/書き込み/デバッグを容易にすることができます。
また、将来の結合の実行方法を1か所で変更することもできます。おそらく、1対多の関係が多対多の関係になり、結合に追加のテーブルが導入される可能性があります。または、非正規化して各イベントレコードにすべてのイベントタイプフィールドを含めて、毎回参加する必要がないようにすることもできます(クエリ実行時間のトレーディングスペース)。
後でテーブルをさらに分割して3方向結合に変更することもでき、ビューを使用する他のクエリを書き直す必要はありません。
テーブルに新しい列を追加し、ビューを変更して新しい列を除外して、テーブル定義を変更したときに「select *」を使用する古いクエリが壊れないようにすることができます。