0

一連のテーブルの基本的な SQL-VIEW を作成するのに助けが必要です。ここに簡単な概要があります

  • ClaimDetail テーブルがあり、StatusID、BrandID、SalespersonID などのルックアップ フィールドがいくつかあります。
  • いつものように、ルックアップ フィールドは、MasterStatus、MasterBrand などのマスター テーブルにマップされます。{構造: ID、タイトル}
  • また、コメントとファイルという 2 つのテーブルがあります。クレームには、複数のコメントと複数のファイルを含めることができます。
  • 請求のリストとなるダッシュボードを表示する必要があります。マスター テーブルのタイトルと、コメントとファイルの数を表示する必要があります。

現在、このダッシュボードには 2 つのビューがあります。1 つは特定の詳細に限定された Customer タイプのユーザー用で、もう 1 つは内部ユーザー向けの詳細ビューです。顧客ビューは内部ビューのサブセットであると言えます。

2つのオプションがあります-

  1. オプション #1: vw_Internal ビューを 1 つ作成し、それを使用して両方のユーザーのデータを取得します。
  2. Opt#2: 顧客に必要なフィールドのみを持つ vw_Customer を作成し、vw_Customer INNER JOIN マスター テーブルのようなvw_Internalを作成します。つまり、基本的な vw_Customer を拡張して、より多くのフィールドを含めます。

オプション #2 は、速度とパフォーマンスの観点から理にかなっていますか? Opt#1 は単純ですが、膨大な数のレコードを考慮して、顧客がダッシュボードに含まれない余分なルックアップを待つ必要がないようにしたいと考えています。

最後に、私が言及した最後の機能を利用する方法はありますか? つまり、ClaimDetail テーブルと 1 対多の関係にあるコメントとファイルの数を取得しています。クレームにコメントがあるかどうかを示すカウントまたは少なくともブールフィールドが必要です（ファイルについても同じ）-カウント= 0の場合はfalseになります。この機能によるパフォーマンスへの影響についても心配しています.

前もって感謝します。

4

1 に答える 1

1

ビューの定義に関しては、2 つのビューを作成し、それらを別々に作成します。どちらのビューも他のビューを参照しないようにします。これにより、クエリを独立して最適化することができ、ビューの上にレイヤー化されたビューで発生する問題を回避できます。レイヤーが多すぎると、データベースの管理、保守、およびリファクタリングが特に困難になる可能性があります。

データ集計に関しては、一般的な戦術には次のようなものがあります。比較、対比、テスト、推定を行って、環境に最適なものを見つけてください。

サブクエリ

SELECT mt.Id, st1.HowMany, st2.HowManyOther, <etc>
 from MainTable mt
  inner join (select Id, count(*) HowMany
               from SubTable1
               group by Id) st1
   on st1.Id = mt.Id
  inner join (select Id, count(*) HowMany
               from SubTable2
               group by Id) st2
   on st2.Id = mt.Id

かなり単純ですが、適切なインデックスを作成しても、サブクエリは多少コストがかかる可能性があります。

カウント (個別の xx)

SELECT mt.Id, count(distinct st1.UniqueKey) HowMany, count(distinct st2.UniqueKey) HowManyOther, <etc>
 from MainTable mt
  inner join SubTable1 st1
   on st1.Id = mt.Id
  inner join SubTable2
   on st2.Id = mt.Id

これには、「サブテーブル」に単一の一意の列が必要であり、外部結合または NULL を処理する必要がある場合は面倒です。

追加した

まず、上記のクエリのいずれかで内部結合を (左) 外部結合に置き換えると、サブテーブルから 0+ カウントが生成されますが、カウントが「右側の」テーブルで行われていることを確認する限り (NULL はそうではないため)集計します）。環境でどちらが最適かを判断するには、両方のクエリを作成してテストする必要があります。2番目はサブクエリのテーブルでテーブルスキャンを必要とし、2番目は結合を実行するため、より適切に最適化される可能性があるため、2番目を推測しますが、SQLクエリオプティマイザーは私よりも賢いです（インデックスを認識し、分布ヒストグラムを持っているため）あなたのデータ) だから、あなたはそれが何を思いつくかを見たいと思っています。

「階層化されたビュー」に関しては、ロジックを正しく実行している場合、内部ビューを複雑で包括的なクエリ (すべての結合、関連するすべての列) として構築し、それから Customer ビューを構築することをお勧めします。単純な

SELECT <customerOnlyColumns>
 from vw_Internal
于 2011-07-01T14:09:35.677 に答える