問題タブ [entity-attribute-value]

私は2つのテーブルを持っています:

条件に一致する EAV 内のすべてのサブスクライバーを見つけるために、関係分割を使用します。

これにより、すべての基準を持つ購読者の一意のリストが得られます。つまり、サブスクライバー 1 と 2 は、色が赤でサイズが xl を探しているため、私が戻ってくることを意味します。これがまさに私の基準です。

しかし、これを拡張してサブスクライバー 3 も取得するようにしたい場合はどうでしょう。サブスクライバー 3)。

現在の設計を考えると、クエリを拡張して、0 個以上の属性が定義されているサブスクライバーを含める方法はありますか?また、属性が定義されている場合は、基準に一致する必要がありますか?

または、クエリを支援するためにテーブルを設計するより良い方法はありますか?

私たちのeコマースアプリケーションでは、さまざまな種類の属性を持つさまざまな種類の製品があります。たとえば、靴は食用ケーキとは異なる販売機能を備えています。私たちのeコマースサイトでは、さまざまな属性と値を選択して、独自の製品を「構築」できます（カップケーキのピンクのフロスティングなど、コストに$ .25が追加されます）。

私たちの最初の建設はこのように見えました。これは維持すべきナイトメアです。 これらのテーブル（またはオブジェクト）をより正規化された現実的な方法で組み立てる方法についての提案を探しています。

これよりも多くのフィールドを持つかなり標準的な製品テーブルがありますが、次のようなアイデアが得られます。

特定のオプショングループに対して選択できるすべてのオプションを一覧表示するオプションテーブルがあります（単一のドロップダウンリストを考えてみてください）。

次に、これらの両方を結び付ける多対多のテーブルがあります。ここで、レコードの存在は、その製品にオプションを結び付けます。

すべてのケーキは一般的に同じフレーバーを持ち、すべてのアイシングは一般的に同じ色を持っているなど、同様のオプションを同様の製品に割り当てようとしています。オプションを変更すると、関連するすべての製品が変更されます。

特にDDDの方法で、どんな提案も最も高く評価されます。

SQL での Entity-Attribute-Value データベース設計の主な欠点はすべて、データのクエリとレポートを効率的かつ迅速に実行できることに関連しているようです。この件に関して私が読んだ情報のほとんどは、これらの問題と、ほとんどすべてのアプリケーションのクエリ/レポートの共通性のために、EAV の実装に対して警告しています。

私は現在、エンティティの 1 つのフィールドが設計/コンパイル時に不明であり、システムのエンド ユーザーによって定義されるシステムを設計しています。EAV はこの要件に適しているように思えますが、私が読んだ問題のために、このシステムにもかなり重いレポート要件があるため、実装をためらっています。私はこれを回避する方法を思いついたと思いますが、SO コミュニティに質問を投げかけたいと思います。

典型的な正規化されたデータベース (OLTP) がレポートを実行するための最良の選択肢であるとは限らないことを考えると、正規化されたデータベースからのデータがコピーされ、広範囲にインデックスが作成され、クエリを容易にするために非正規化されている可能性があります。EAV 設計の欠点を回避するために同じアイデアを使用できますか?

私が見た主な欠点は、EAV データベースで新しいフィールドが定義されているため、レポート データベースのテーブルを変更しなければならない可能性があるため、EAV データベースからレポートにデータを転送する際の複雑さが増すことです。しかし、それはほとんど不可能ではなく、EAV 設計によってもたらされる柔軟性の向上とのトレードオフとしては許容できるようです。すべての標準レポート ツールは SQL バックエンドに対してクエリを実行することを想定しているため、メイン データ ストレージに非 SQL データ ストア (つまり、CouchDB など) を使用する場合にも、この欠点が存在します。

クエリ用に別のレポート データベースを使用すると、EAV システムの問題はほとんどなくなりますか?

編集：これまでのコメントをありがとう。私が取り組んでいるシステムに関する重要なことの 1 つは、システム内のすべてではなく、エンティティの 1 つに EAV を使用することだけを話しているということです。

システムの全体的な要点は、事前に知られていない複数の異なるソースからデータを引き出し、データを処理して、特定のエンティティに関する「最もよく知られている」データを作成できるようにすることです。したがって、私が扱っているすべての「フィールド」は多値であり、それぞれの履歴を追跡する必要もあります。このための正規化された設計は、フィールドごとに1つのテーブルになるため、とにかくクエリを実行するのが面倒になります。

これが私が見ているテーブルスキーマとサンプルデータです（明らかに私が取り組んでいるものから変更されていますが、それは要点をよく示していると思います）：

EAV テーブル

レポート表

正規化された設計

ここでの「Confidence」フィールドは、SQL を使用して (たとえあったとしても) 簡単に表現できないロジックを使用して生成されるため、新しい値を挿入する以外の最も一般的な操作は、すべてのフィールドの人物に関するすべてのデータを取得することです。レポートテーブル。これは、単一のクエリを実行できるため、EAV モデルの方が実際には簡単です。正規化された設計では、大規模なデカルト積がそれらをすべて結合するのを避けるために、フィールドごとに 1 つのクエリを実行する必要があります。

各製品に多くのパラメータがある多くの種類の製品の製品テーブルを設計する方法で支持されているのと同様の問題があります

私は今RDFを使うと確信しています。上記の問題への回答でビル・カーウィンが行ったコメントの1つだけが理由です

しかし、私はすでにmysqlにデータベースを持っており、コードはphpにあります。

1）では、どのRDFデータベースを使用する必要がありますか？

2）アプローチを組み合わせますか？つまり、mysqlデータベースにクラステーブル継承があり、RDFに奇妙な製品属性があるだけですか？問題を引き起こしているのは単なる製品であり、考えられる属性と値の幅広い配列であるため、すべてをRDFデータベースに移動する必要があるとは思いません。

3）どのphpリソース、記事を見る必要がありますか？これは、これを作成するのに役立ちますか？

4）あらゆる種類の製品の属性と価値をよりよく保持する何かを構築するという上記の課題の文脈で、RDFをよりよく理解するのに役立つ記事やリソースが増えれば幸いです。何が起こっているのかを概念的に理解していると、うまくいく傾向があります。

私はこれに完全に初心者であり、プログラミングとデータベースに関する私の知識はせいぜい平均的であることを覚えておいてください。

Java/Spring MVC と Hibernate を使用して、Web アプリで単純な EAV パターンをセットアップしようとしています。このシナリオの休止状態の XML セットアップの背後にある魔法を理解できないようです。

私のデータベース テーブル "SETUP" には 3 つの列があります。

• ユーザー ID (外部キー)
• setup_item
• セットアップ値

データベース複合キーは、user_id |で構成されます。setup_item

Setup.java クラスは次のとおりです。

Hibernate セットアップに関する私の問題は、外部キーとマップのキーがテーブルの複合キーを構築するという事実をマップする方法を理解できないように見えることです...これは不足によるものですHibernate の使用経験。これを機能させるための私の最初の試みは次のとおりです。

この一般的なシナリオを適切にマッピングする方法についての洞察をいただければ幸いです。

多くの人がそうであるように、私はProducts /Product Propertiesデータベース スキーマを探しています。ファセット検索には Ruby on Rails と (Thinking) Sphinx を使用しています。

要件：

• 新しい製品タイプとそのオプションを追加しても、データベース スキーマを変更する必要はありません。
• Sphinx を使用したファセット検索をサポートします。

私が遭遇した解決策：
（Bill Karwinの回答を参照）

オプション 1: 単一テーブルの継承

本当にオプションではありません。テーブルには、多くの列が含まれます。

オプション 2: クラス テーブルの継承

Ruby on Rails は、起動時にデータベース スキーマをキャッシュします。これは、新しいタイプの製品が導入されるたびに再起動することを意味します。十分なサイズの製品カタログがある場合、これは数百のテーブルを意味する可能性があります。

オプション 3: シリアル化された LOB

複雑なアプリケーション ロジックなしでファセット検索を実行できることは致命的です。

オプション 4: エンティティー属性値

テスト目的では、EAV は問題なく動作しました。ただし、オプションを追加すると (オプションによって価格や納期が増加する場合など)、すぐに混乱してメンテナンス地獄になる可能性があります。

どのオプションを使用する必要がありますか? 他にどのようなソリューションがありますか? 私が見落としていた特効薬（ハ）はありますか？

10万件を超えるレコードを持つデータベースがあります。多くのカテゴリと多くのアイテム（カテゴリごとに異なるプロパティを持つ）すべてがEAVに保存されます。

このスキームを破って、任意のカテゴリに対して一意のテーブルを作成しようとすると、回避する必要がありますか？

はい、おそらく私はたくさんのテーブルを持っていることを知っています、そして私が余分なフィールドを追加したいのなら私はそれらを変更する必要があるでしょう、しかしこれはとても間違っていますか？

また、私が持っているテーブルの数が多いほど、dbにはさらに多くのファイルが読み込まれ、これはどのファイルシステムにも適していません。

なにか提案を？

NH を活用して、EAV/CR データ モデルの大まかな解釈であるデータ モデルにマップしようとしています。

私はそれのほとんどを機能させていますが、Entity.Attributes コレクションのマッピングに苦労しています。

問題のテーブルは次のとおりです。

AttributeValue 列は sql_variant 列として実装されており、そのために NHibernate.UserTypes.IUserType を実装しました。

EntityAttribute エンティティを作成し、それを直接永続化して、階層の一部が機能するようにすることができます。

EntityAttributes コレクションを Entity エンティティにマップする方法がわかりません。

EntityAttributes テーブルには、特定の EntityId/AttributeId の組み合わせに対して複数の行が含まれる可能性がある (実際に含まれている) ことに注意してください。

この例では、StringAttributes 行は次のようになります。

Entity.Attributes("FavoriteColors") がお気に入りの色のコレクションを返すように、このデータ モデルをエンティティ ドメインに効果的にマップするにはどうすればよいですか? System.String として入力されましたか?

私はこのテーブルを持っています

そしてこのテーブル

id_attribute=1 の ATTRIBUTE_VALUE から選択し、存在する場合 (UMS.value=ATTRIBUTE_VALUE.ums) から UMS.order end で並べ替え ATTRIBUTE_VALUE.value でグループ化する場合

出力の例:

動的アプリケーションを構築しています。私は3つのテーブルを持っています:(EAVモデルスタイル)

1. アイテム (アイテム ID、アイテム名)
2. フィールド (FieldId、FieldName)
3. フィールド値 (ItemID、FieldId、Value)

FieldId=4 が TRUE に等しいすべてのアイテムから 20 レコードを取得するための SINGLE クエリの書き方を教えてください。

期待される結果 ：

重要な懸念事項:

1. アイテムごとのフィールド数は不明
2. 1 つのクエリを作成するために 1 つ必要です。
3. クエリは 100K レコードに対して実行されるため、パフォーマンスが懸念されます。
4. MySQL 5.0 を使用しているため、MYSQL のソリューションが必要です

上記のクエリがまったく不可能な場合、テーブルを非正規化する必要がありますか? 何かアドバイス ？