0

車に関するウェブサイトを構築しているとしましょう。車のエンティティには、列挙型のような属性がたくさんあります。

  • トランスミッション（手動/自動）
  • 燃料（ガソリン/ディーゼル/バイオエタノール/電気）
  • ボディスタイル（クーペ/セダン/コンバーチブル/ ...）
  • エアコン（なし/シンプル/デュアルゾーン）
  • 外装色（黒/白/グレー/青/緑/ ...）
  • インテリアカラー（ブラック/ホワイト/グレー/ブルー/グリーン/ ...）
  • 等

これらの属性のリストは、将来変更される可能性があります。データベースでそれらをモデル化するための最適な方法は何ですか？私は次のオプションを考えることができますが、実際には決定できません：

  • car列挙値を持つテーブル のフィールドを使用する
    • 後で列を追加するのは難しい、おそらく最速
  • carルックアップテーブルを参照する外部キーであるテーブル 内のフィールドを使用する
    • 後で列を追加するのは難しく、やや遅くなります
  • 可能な値を格納する属性ごとに個別のテーブルを作成し、車と属性値の間の接続を格納する別のテーブルを作成します
    • 後で可能な値を追加するのは簡単ですが、さらに遅くなりますが、複雑すぎるようです
4

6 に答える 6

1

理想的には、リレーショナルデータベースを作成することです。DBの各テーブルは、休止状態の場合と同様に、クラスで表す必要があります。車用に2つのテーブルを作成する必要があります。1つは車の内装用、もう1つは車の外装用です。機能を追加したい場合は、列を追加するだけです。

于 2012-11-16T22:53:28.110 に答える
1

これが（非常に基本的な）EAVモデルです。

DROP TABLE IF EXISTS example.zvalue CASCADE;
CREATE TABLE example.zvalue
        ( val_id SERIAL NOT NULL PRIMARY KEY
        , zvalue varchar NOT NULL
        , CONSTRAINT zval_alt UNIQUE (zvalue)
        );
GRANT SELECT ON TABLE example.zvalue TO PUBLIC;

DROP TABLE IF EXISTS example.tabcol CASCADE;
CREATE TABLE example.tabcol
        ( tabcol_id SERIAL NOT NULL PRIMARY KEY
        , tab_id BIGINT NOT NULL REFERENCES example.zname(nam_id)
        , col_id BIGINT NOT NULL REFERENCES example.zname(nam_id)
        , type_id varchar NOT NULL
        , CONSTRAINT tabcol_alt UNIQUE (tab_id,col_id)
        );
GRANT SELECT ON TABLE example.tabcol TO PUBLIC;

DROP TABLE IF EXISTS example.entattval CASCADE;
CREATE TABLE example.entattval
        ( ent_id BIGINT NOT NULL
        , tabcol_id BIGINT NOT NULL REFERENCES example.tabcol(tabcol_id)
        , val_id BIGINT NOT NULL REFERENCES example.zvalue(val_id)
        , PRIMARY KEY (ent_id, tabcol_id, val_id)
        );
GRANT SELECT ON TABLE example.entattval TO PUBLIC;

ところで：これはシステムカタログをサポートするように調整されています。いくつかの変更が必要になる場合があります。

于 2012-11-16T23:14:40.137 に答える
1

これは実際にはこのdba.SEの投稿の複製です。

https://dba.stackexchange.com/questions/27057/model-with-variable-number-of-properties-of-different-types

hstore、json、xml、EAVパターンを使用してください...その投稿の私の答えを参照してください。

于 2012-11-17T00:00:33.550 に答える
0

クエリの数とデータベースのサイズに応じて、次のいずれかを実行できます。

  1. 幅の広いテーブルを作る
  2. 属性テーブルとcar_attributesテーブルを作成します。ここで：cars-> car_attributes-> attribute

＃1は結合が少ないため、クエリがより速く簡単になりますが、＃2はより柔軟です

于 2012-11-16T22:58:49.990 に答える
0

サポートする必要があるのは管理UI次第です。

  • たとえば、送信の種類を管理するためのインターフェイスがある場合は、これを別のエンティティに保存する必要があります。（オプション3）
  • そのようなインターフェースがない場合は、列挙可能なタイプの値のように格納するのが最善です。別のものが必要な場合（たとえば、送信用に「半自動」）、これをDBスキーマにのみ追加します。実際のところ、これはサポートが最も簡単で、実行が最も高速です。
于 2012-11-16T23:00:53.710 に答える
0

列AttributeID、CarID、PropertyName、PropertyValueを使用してテーブルCarAttributesを作成します。reslutセットが返されると、IDictionaryに保存されます。これにより、新しい列を追加せずに、必要な数の行を追加できます。

于 2012-11-16T23:51:59.253 に答える