2

ほとんどの場合、数十の列が既に入力されているモデルがあります。次に、毎回異なる可能性のあるフィールドを追加する必要があります。

最善のアプローチは何ですか？私はEAVパターンが好きではありません。特に、これらの追加のプロパティがどのように大きく異なる可能性があるかを考えると、スパーステーブルを使用するというアイデアも好きではありません。

例：

WorkOrder:
PK id
FK assigned_to
FK contractor
DATE expected_completion
DATE actual_completion
... (many more)

次に、次のようなプロパティを追加します。

ep_1 (extra_property)
ep_2
ep_3
ep_4
... (many more)

これらの追加のプロパティはレコードごとに大きく異なる可能性があり、ほとんどの場合、それらの数は限られていますが、保証はありません。

レコードを次のように考えてください。

id  |  assigned_to  | contractor  | ... | ep_1   | ep_2  | ep_3 | ... | ep_n
1   |  2            | 3           | ... | XYZ    | NULL  | NULL | ... | 23
2   |  3            | 5           | ... | NULL   | 1     | NULL | ... | NULL
3   |  2            | 1           | ... | NULL   | 0     | NULL | ... | NULL
4   |  4            | 1           | ... | XYZ    | NUL   | NULL | ... | 45

これらの追加のプロパティが実際に列であるかのように、レコードを一覧表示、フィルタリング、および検索できるようにしたいです。たとえば、次のようなクエリを実行できる必要がありますSELECT fields FROM table WHERE ep_n > 20。SELECT fields FROM table WHERE ep_1='ABC'

これに対する最善の解決策は何ですか？

4

1 に答える 1

3

どのデータベースですか？たとえばSQLServerでは、スパーステーブル用に最適化されたスパース列の使用を検討できます。EAVモデリングについては、SQL Serverカスタマーアドバイザーチームからの主題に関するホワイトペーパーを読むことをお勧めします：パフォーマンスとスケーラビリティのためのセマンティックデータモデリングのベストプラクティス。推奨事項の多くは他のベンダーにも適用されますが、SQLServer固有のものではありません。

于 2010-08-15T03:10:34.957 に答える