0

Type_of_installations というテーブルがあります。、、などcostの共通フィールドを持ついくつかのタイプが含まれています。guarantee_endmanufacturer

ただし、次のような一部のタイプのみに関連する機能があります。

voltage, capacity, hours_per_week, lifting_power, weight, ...

これらは、一部の機能のみで存在する場合があります。私が覚えている 1 つの方法は、各イレギュラー フィーチャの後にビット フィールドを追加することですが、これを処理するためのより効率的な手法があると思います。毎回、すべての不規則な機能ビットをチェックするのは面倒だと思います。これは、処理時間が長くなるというよりは、プログラミングに時間がかかります。

一部の属性がメイン テーブルの一部の行にのみ関連する一連のテーブルを設計する最善の方法は何ですか?

4

3 に答える 3

3

ビットフィールドは機能します。より複雑になる別の方法は、EAVスタイルで行うことです。

「インストール」テーブルフィールド：id、guarantee_end、manufacurer
「オプション」テーブルフィールド：install_id、option_name、option_value

したがって、必須フィールドを含む「インストール」テーブルがある場合は、次のようになります。

id guarentee_end manufacurer
 1 20140101 IBM
 2 20140701 Lenovo

「オプション」テーブルには次のものがあります。

install_id option_name option_value
 1コスト1000.00
 1色グリーン
 2fooバー

それらの可能なオプションが何であるかを厳密に定義する必要なしに、レコードごとに必要な数を超えて保存することはありません。必要に応じてそれらを追加し、install_idフィールドに参加してクエリを実行します。

于 2013-01-03T18:10:42.113 に答える
2

常に一緒に表示されるこれらのオプションの列のサブセットを定義できる場合は、それぞれがサブセットを含み、外部キーを使用してメイン テーブルにリンクされているサブテーブルを作成できます。

何かのようなもの：

MainTable(id int, guarantee_end int, manufacturer int)
Electric(id int, voltage float, watts float, mainTableID int foreign key)

編集:それ以外の場合は、フィールドが使用されていないときにフィールドを NULL にするだけです。ビットフィールドは必要ありません (ほとんどの場合)。NULL フィールドを上記と組み合わせて、合理的に効率的で適切な構造化された組み合わせを得ることができます。

于 2013-01-03T18:15:11.483 に答える
2

この種のデータには、NoSQL の方が適している可能性があります。

個々のプロパティに興味がない場合、たとえば select * from Things Where Lifting_power > 400 の場合は、xml またはシリアライゼーションが適しています。

よく使われるが愚かなことを除いて、考えられるすべての列をテーブルに入れることを除けば、古典的なプロパティバッグが最善の策です

Thingy (ThingyID、ThingyName など) プロパティ (PropertyID、PropertyName、PropertyType など)、デフォルト、min および max のすべての種類がここに表示されます

PropertiesOfThingys(ThingyID, PropertyID, PropertyValue) PropertyValue は文字列であり、変換には PropertyType を使用します

一種の

于 2013-01-03T18:15:44.593 に答える