[解決済み] ユーザー定義フィールドのデータベースを設計するには？

質問

私の要求事項は

• 任意のデータ型のユーザー定義フィールドを動的に追加できるようにする必要があります。
• UDFのクエリーを迅速に行う必要がある
• UDFでデータ型に応じた計算ができるようにしたい
• データ型に基づいたUDFのソートが可能である必要がある。

その他の情報

• パフォーマンスを中心に探しています
• UDFデータを添付できるマスターレコードが数百万件あります。
• 前回確認したところ、現在のデータベースには5,000万件以上のUDFレコードがありました。
• ほとんどの場合、UDFはマスター・レコードのすべてではなく、数千件にしか添付されません。
• UDFは結合されたり、キーとして使用されることはありません。クエリーやレポートに使用される単なるデータです。

オプションです。

1. StringValue1、StringValue2...で大きなテーブルを作成します。IntValue1、IntValue2、...など。私はこのアイデアが嫌いですが、誰かがそれが他のアイデアよりも優れていて、その理由を教えてくれるなら、それを考慮するつもりです。

2. 必要に応じて新しいカラムをオンデマンドで追加する動的テーブルを作成する。また、このアイデアは、すべてのカラムにインデックスを付けないとパフォーマンスが低下するような気がして、あまり好きではありません。

3. UDFName、UDFDataType、Valueを含む1つのテーブルを作成する。新しいUDFが追加されたら、そのデータだけを取り出し、指定されたタイプにパースするViewを生成します。パース基準を満たさない項目はNULLを返します。

4. データ型ごとに1つずつ、複数のUDFテーブルを作成する。つまり、UDFStrings、UDFDatesなどのテーブルを持つことになる。おそらく、#2と同じように、新しいフィールドが追加されるたびにViewを自動生成することになるだろう。

5. XML DataTypes？私はこれらを扱ったことはありませんが、言及されているのを見たことがあります。特にパフォーマンスについては、私が望む結果を得られるかどうかはわかりません。

6. 他に何か？

解決方法は？

もしパフォーマンスを第一に考えるなら、私なら#6...UDFごとにテーブルを用意します（本当は#2の変形です）。この回答は、特にこの状況と、記述されたデータの分布とアクセスパターンの記述に合わせたものです。

長所

1. 一部の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つのテーブルを作る必要がない。 の場合、必要な結合は2つ少なくなります。 3つのカラムすべてにアクセスする必要があります。

2. からのパフォーマンスの壁にぶつかったら 人口が多いUDF 頻繁に使用されるものであれば、それは に含めることを検討します。 マスターテーブルを使用します。

3. 論理的なテーブル設計を行うことで あるところまではいいのですが、レコード というのも、本当に膨大な数になってくると を検討する必要があります。 が提供するパーティショニングオプションを使用することができます。