ユーザー定義フィールドのデータベースを設計するにはどうすればいいですか? 質問する

パフォーマンスが主な懸念事項である場合は、#6...UDF ごとに 1 つのテーブル (実際、これは #2 のバリエーションです) を採用します。この回答は、この状況と、説明されているデータ分散およびアクセス パターンの説明に合わせて特別に調整されています。

長所:

1. 一部の UDF にはデータ セット全体のごく一部の値が含まれているため、テーブルのサイズは UDF をサポートするために必要なサイズだけになるため、別のテーブルを使用すると最高のパフォーマンスが得られます。関連するインデックスについても同様です。

2. また、集計やその他の変換のために処理する必要があるデータの量を制限することで、速度が向上します。データを複数のテーブルに分割すると、UDF データに対して集計やその他の統計分析を実行し、その結果を外部キーを介してマスター テーブルに結合して、集計されていない属性を取得できます。

3. 実際のデータを反映するテーブル名/列名を使用できます。

4. データ ドメインを定義するために、データ型、チェック制約、デフォルト値などを完全に制御できます。オンザフライのデータ型変換によって生じるパフォーマンスの低下を過小評価しないでください。このような制約は、RDBMS クエリ オプティマイザーがより効果的なプランを開発するのにも役立ちます。

5. 外部キーを使用する必要がある場合、組み込みの宣言的参照整合性よりも、トリガー ベースまたはアプリケーション レベルの制約の適用の方が優れていることはほとんどありません。

短所:

1. これにより、多数のテーブルが作成される可能性があります。スキーマ分離や命名規則を強制すると、この問題は軽減されます。

2. UDF の定義と管理を実行するには、さらに多くのアプリケーション コードが必要です。元のオプション 1、3、4 よりも必要なコードは少なくなると予想されます。

その他の考慮事項:

1. データの性質上、UDFをグループ化する意味がある場合は、それを推奨します。そうすれば、それらのデータ要素を1つのテーブルにまとめることができます。たとえば、色、サイズ、コストのUDFがあるとします。データの傾向として、このデータのほとんどのインスタンスは次のようになります。

    'red', 'large', 45.03 
   

   それよりも

    NULL, 'medium', NULL
   

   このような場合、3 つの列を 1 つのテーブルに結合しても、NULL 値はほとんどなく、2 つのテーブルを追加で作成する必要もないため、速度に顕著な低下は発生しません。つまり、3 つの列すべてにアクセスする必要がある場合に必要な結合が 2 つ少なくなります。

2. データが大量に含まれ、頻繁に使用される UDF でパフォーマンスの壁にぶつかった場合は、それをマスター テーブルに含めることを検討する必要があります。

3. 論理テーブル設計はある程度までは可能ですが、レコード数が本当に膨大になると、選択した RDBMS によって提供されるテーブル パーティション オプションも検討する必要があります。