0

非常に異なる属性を持つさまざまなエンティティを持つシナリオに EAV パターンを使用します。

「基本的な」EAV パターンは 3 つのテーブルで構成されています。属性ごとに異なるデータ型 (日付、ロング、ブール値など) があるため、現在、これを解決する方法を考えています。

最初の方法は、すべてを文字列として保存することです。これには「解析」が必要であり、「1」のような数値を持つことは、これが double、boolean などの場合、直接表示されません。属性値テーブルは次のようになります

id|attribute_id|entity_id|value
1  2            3         17.0
2  4            2         Foobar

2 番目の方法は、さまざまな型をさまざまな列に分割し、次のように値の列を null 可能にすることです。

id|attribute_id|entity_id|value_string|value_long|value_float|value_date
1  2            3         NULL         NULL       17.0        NULL
2  4            2         Foobar       NULL       NULL        NULL

ただし、これは基本的に決定がEAVパターンにつながる理由である多くのNULL値を生成します（未使用の列のNULL値を減らします）

したがって、これは、型付き属性テーブルを作成するという 3 番目の可能な解決策につながります。

attribute_values_string
id|attribute_id|entity_id|value
2  4            2         Foobar

attribute_values_float
id|attribute_id|entity_id|value
1  2            3         17.0

ただし、これによりクエリがより複雑になります。常にnテーブルにattribute_value. また、このように使用するとattribute_ids、すべてが独自の auto_increment を使用している場合、異なる値の型が等しくなります。idそのため、値を別の型に変換することは、維持できないため、やや注意が必要です。もちろん、これattribute_valuesは、auto_increment 値を提供し、おそらくいくつかの型情報やメタデータを含む別の型指定されていないテーブルを追加することで回避できます。(バージョニング/リビジョンを使用する必要があるため、自動生成された attribute_values_ids をとにかく使用することはできません。2 つのリビジョンが同じ ID を共有する必要があるためです)

したがって、最初に決定するのはレイアウトです。EAVを使用した経験のある人はいますか? 各試行のボトルネックは何ですか?

4

3 に答える 3

1

NULL アプローチを使用します。Else クエリは一般に、より多くのリソースを必要とします。

SQL Server 2008 には、役立つスパース列がいくつか用意されています。

また、エンティティの Instance_Id 列を見逃していることもわかります。エンティティには属性があり、そのエンティティのインスタンスが多数あります。GUIDにリンクする必要があります

于 2013-06-01T08:15:30.803 に答える
1

Fwiw、私はあなたの最初のスキーマとあなたの 2 番目のスキーマのバリエーションでまともな経験をしました。(型列、単一値列、および適切な式の部分インデックス、つまりキャストされたデータ。MySQL を使用して得られる最も近いものは、2 番目のスキーマです。つまり、関心のある型ごとの列です。)

2 番目のスキーマにインデックスを追加する場合は、value_string (列挙型など、インデックスを作成する短い文字列の場合) と value_text (インデックスを作成しない長いテキストの場合) を区別することを忘れないでください。

ただし、長期的には、通常の警告と警告とともに、実際には最初のオプションをお勧めします。EAV テーブルの唯一の合理的な長期使用例は、構造が定義されておらず、その中に格納されている実際のデータが表面的なものである場合です。ここでの操作用語は未定義で表面的なものです。EAV テーブル内のデータに対して実際にクエリを実行する必要がある場合はいつでも、新しい列に対応するためにスキーマをどのように変更する必要があるかを自問する必要があります。そうしないと、クエリが遅くなります。

于 2013-06-01T09:23:31.170 に答える
0

Null値を減らそうとするあなたの見解は理解していますが、5つの正規形は常にこの問題を解決できると信じています. 属性のリアルタイムまたはオンデマンドの追加を要求する顧客がいる場合は、EAV モデルに同意します。

私が見る他の多くの問題の中で：

  1. 属性名を制御し、一貫性を持たせることは困難です。
  2. データ型の整合性と参照整合性を強制することは困難です。
  3. 値をピボットおよび/または自己結合して単一の行を作成することは困難です (そして時間がかかります)。
  4. 特定の属性を必須にすることは困難です。

私はMagentoを使用してきました.Magentoは、「正常に」動作するために大量のキャッシュと補助テーブルを要求します.もちろん、それを実行し続けるサーバーは堅牢なサーバーでなければなりません. あなたのアプリケーションはもっと小さいかもしれません。

とにかく、それは私の意見です、あなた、犬鼻は、この他の視点をチェックして、あなた自身の結論を出すこともできます

于 2013-04-23T08:49:46.880 に答える