4

という名前のテーブルassetsがあり、アセットはユーザー、チーム、または部門に属することができ、場合によってはそれぞれの複数に属することができます。私の問題は、アセットが非常に可変的であり、アセットごとに異なるプロパティが関連付けられている可能性があることです。

元。これらはアセットである可能性があります:

1.)
type:workbench
cost:200
vendor:Acme Co.
color:black
2.)
type:microscope
serial_no:BH-00102
purchase_date:1337800923
cost:2040

これは、数百から数千の異なる種類の資産に適用される可能性があります。

新しいアセット タイプが追加されるたびにテーブルを変更せずに、このタイプのデータをクエリしやすい正規化された方法で保存するにはどうすればよいでしょうか? 一部のフィールドは、コストなど、すべての資産にも存在します。

これまでのところ、私は持っているべきだと考えています:

assets
id,cost,purchase_date,asset_type_id

asset_types
id,name

division_assets
division_id,asset_id

user_assets
user_id,asset_id

しかし、私は変化するデータをどこに置くべきかわかりません

4

5 に答える 5

3

私はこれを提案します：

assets (

   id
   asset_type_id
   vendor_id
   cost
   purchase_date

)

asset_poperties (

    id
    asset_id
    asset_property_type_id
    value

)

asset_property_types (

     id
     property_type

)

asset_types (

   id
   asset_type

)

vendors (

   id
   vendor

)
于 2013-02-17T07:43:56.927 に答える
3

過去にこれに直面したとき、「最良の」答えは、データベースで実行したい処理の量とクライアントコードでの処理量によって常に異なります。

価値があるのは、過去に私にとって最も効果的だったアプローチは、オプションの属性ごとに 1 つのテーブルになることでした (特に、エンティティの種類ごとに 1 つのテーブルではありません)。したがって、上記の例では

assets (as per your example)
asset_types (as per you example)
division_assets (as per your example)
user_assets (as per your example)
colours
  asset_id, colour
weights
  asset_id, weight
serial_numbers
  asset_id, serial_number

もちろん、必要なトレードオフによっては、これは適切な選択ではない可能性があります。個人的には、データ型や制約を含め、データのスキーマを可能な限り明示的に保つのが好きなので、次に新しい属性が登場したときにテーブルを変更してもドラマはありません。

于 2013-02-17T08:49:57.107 に答える
2

Asset_metadataに別のテーブルを追加できます

asset_metadata
asset_metadata_id,asset_id,metadata_name,metadata_value

メタデータを正規化して分類する場合は、次のように正規化します。

asset_metadata
asset_metadata_id,asset_id,metadata_name_id,metadata_value

metadata_name
metadata_name_id,metadata_name_text
于 2013-02-17T07:50:54.560 に答える
2

コストなどの一般的な属性を従来の列に入れることをお勧めします。次に、他のすべての可変アセット属性のシリアル化されたコレクションを配置する列をもう1つ追加します。

CREATE TABLE assets (
  asset_id INT AUTO_INCREMENT PRIMARY KEY,
  cost NUMERIC(9,2),
  purchase_date DATE,
  variables TEXT
);

コレクションは、JSONやXMLなど、必要に応じてシリアル化できます。アプリケーションコードで最も簡単に処理できるものを使用してください。

INSERT INTO assets VALUES (123, 49.95, CURDATE(), 'color: black; vendor: Acme Co.');

利点は、いつでもテキストブロブに新しい属性を追加できることです。欠点は、個々の属性の読み取りまたは書き込みができないことです。コレクション全体をまとめて処理する必要があります。

ただし、個々の属性にインデックスを付けて検索可能にすることができます。検索可能にする属性ごとに新しいテーブルを作成する必要があります（ただし、これはすべての属性の小さなサブセットである可能性があります）。

CREATE TABLE asset_color (
  asset_id INT NOT NULL,
  color VARCHAR(10),
  PRIMARY KEY (asset_id, color),
  KEY(color)
);

すべてのアセットがこのテーブルに記録されるわけではなく、色の付いたアセットのみが記録されます。

次に、色属性を持つすべてのアセットのインデックス検索を実行できます。

SELECT assets.*
FROM assets INNER JOIN asset_color USING (asset_id);

また、色属性があり、色が黒であるアセットに限定してインデックス検索を実行することもできます。

SELECT assets.*
FROM assets INNER JOIN asset_color USING (asset_id)
WHERE color = 'black';

変数属性を許可する正規化されたデータベースを設計する方法は実際にはありません。すべての正規形では、最初にテーブルがリレーションである必要があります。また、関係は定義上、固定された属性のセットを持っている必要があります。

他の人々はEAVテーブルを推奨していますが、EAVの「値」列はタイプを持つリレーショナル列の定義を満たしていません（これの他の結果は、制約がEAVテーブルで機能しないことです）。したがって、EAVテーブルはリレーションではなく、通常の形式も満たすことができません。

于 2013-02-17T08:28:06.103 に答える
-1

次の 2 つの新しいテーブルを作成できます。

1) 次の表で複数のアセット属性を定義する (アセットが持つ可能性のある数だけ)

asset_id

資産属性

資産価値

2) asset_attribute テーブル

attribute_id

資産属性

ロジックは、asset_attributes を最初に asset_attribute テーブルで定義する必要があり、その後、任意のアセット (UI のドロップダウン リストから外部キーとして) と適切な値を入力して使用 (リンク/タグ付け) できるというものです。

お役に立てれば。

于 2013-04-20T05:16:12.957 に答える