0

2 つのデザインのパフォーマンスについて質問があります。目標は、いくつかの属性を共有しながらも異なる、複数のタイプのエンティティを格納することです。

アプローチ 1: 複数のテーブル、それぞれが 1 つのエンティティをモデル化する

Entity1 - C1, C2, C3
Entity2 - C1, C2, C4
Entity3 - C1, C2, C5

クエリを実行するにはUNION ALL、すべてのテーブルに対して a を実行する必要があります。

アプローチ 2: すべての列と型列を含む単一のテーブル

All - Type, C1, C2, C3, C4, C5

ここでは、列に対して直接クエリを実行できます。

問題は、UNION ALLアプローチにパフォーマンスの問題があるかどうかです。この質問は、回答されていない PostsgreSQL に関する以前の質問に似ています。

編集：

すべての回答に感謝します。

エンティティ テーブルには日付のインデックスが付けられます。また、クエリはほとんどの場合、日付がフィルター処理されているか、共有フィールドがフィルター処理されています。C1 が日付で、C2 が文字列で、クエリの 95% が C1>=from および C1<=to、または C2='SomeId' のように見えるとします。

レコード数はゆっくりと増加し、1 エンティティあたり 1 日あたり数百程度になる可能性があります。列の数は 150 を超えることはありません。ただし、共有される列の数は少ないです。現在、各エンティティは共有以外のフィールドを主キーとして使用する可能性があるため、アプローチ1を実装しています。このようにして、制約はより自然になります。

4

3 に答える 3

2

この選択を行う際には、必要なテーブルの幅、共有列があるかどうか、テーブルの大きさ、テーブルに対して実行するクエリの種類などに大きく依存します。

経験則として、テーブルの幅がデータベースがサポートするレコードの最大幅に近い場合は、1 つのテーブルに配置しないでください。テーブルの幅が狭いほど、パフォーマンスが向上する傾向があります。話している列がほとんどない場合は、これがおそらく最良の解決策です。

共通の列が最も頻繁にクエリされる列である場合は、共通の列を持つ親テーブルと、型固有の列用の 3 つの子テーブルを設計することを検討してください。

共通の列がほとんどなく、通常はタイプが単独でクエリされる可能性が高い場合 (タイプ a とタイプ B の両方が、最も頻繁に実行されるタイプのクエリの結果セットに含まれることは通常ありません)、テーブルを分割して、それらすべてを照会する必要がある数回の UNION all は機能します。

レポート用にすべての種類のクエリを実行するだけで、通常の日常業務のすべてをクエリする必要がない場合は、レポート用に別のテーブルとデータ ウェアハウスを用意することを検討してください。

于 2013-08-06T17:16:12.570 に答える
1

おおよそ何列を予定していますか？私はこのような大きなテーブルを使用した経験があり、単一テーブルのアプローチを採用しましたが、インデックスの 1 つにヒットしない限り、データを取得するのが非常に遅くなります (テーブルは約 250 列 x ほぼ 10 億行です)。

列の数が多いため、一般的なフィルター基準ごとにインデックスを構築することは現実的ではありません。トランザクション システムでの挿入が大幅に遅くなるからです。この例は、テーブルが別々で、すべてのデータを一緒にクエリする必要がある場合にそれらをまとめるビューがあれば、確かにずっと簡単になります。

ただし、考慮すべき変数がたくさんあることは承知しています。OLTP ではなく主に OLAP に使用されるデータベースを使用している場合、たとえば、多くのインデックスを追加することについて心配する必要はないかもしれません。

于 2013-08-06T17:18:15.623 に答える
0

別の方法として、アプローチ 1 と 2 を組み合わせて、「祖先」テーブルを作成することもできます。

All - ID, Type, C1, C2

そして、3 つの「子孫」テーブル。ここで、IDは PK であると同時に、テーブルの FKIDですAll。

Entity1 - ID, C3
Entity2 - ID, C4
Entity3 - ID, C5
于 2013-08-06T19:20:54.273 に答える