0

私たちは、ビジネス タイプごとに 1 つのテーブルを使用して、ビジネス モデルに基づいてデータベースを設計しました。ただし、いくつかの類似したタイプの個別のテーブルを使用するとパフォーマンスの問題が発生するため、各行の実際のサブタイプを識別する識別子列を持つ単一のテーブルにいくつかの関連するテーブルをフラット化することを検討しています。

正規化されたモデルの問題:

  • 他のいくつかのコア テーブルには、これらのサブタイプの 1 つへのポリモーフィック参照があり、参照オブジェクトが含まれるテーブルを決定するためにユニオン ルックアップが必要です。
  • これらのサブタイプの結合全体での検索とインデックス作成は、一般的な操作であり、非効率的です
  • 意味的に同一の列が複数のテーブルで複製されている

Hibernate と JPA を使用しているため、ポリモーフィック ジョインが難しく、ビューを使用できません。

フラット化の短所:

  • 私たちのコードは、データベースで外部キー制限を設定するのではなく、これらのサブタイプの参照型の整合性を担当するようになりました
  • 各行には、その型に関係のない列の null 値があります
  • サブタイプのいずれかに列を追加するには、テーブル全体に列を追加する必要があります
  • 1 つのサブタイプに固有の列を非 null とマークすることはできません

この関連する SO の質問では、正規化された設計を維持することをお勧めしますが、その状況では、サブタイプは合計 100 列のうち 10 列しか共有しませんでした。フラット化されたテーブルには、合計 15 列が含まれます。11 列はすべてのサブタイプで共有され、残りの 4 列は複数のタイプ (すべてではない) で共有されます。

これは、平坦化が理にかなっているシナリオですか?

4

0 に答える 0