8

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

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

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

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

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

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

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

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

EAV テーブル

Person
-------------------
-  Id - Name      -
-------------------
- 123 - Joe Smith -
-------------------

Person_Value
-------------------------------------------------------------------
- PersonId - Source - Field       - Value         - EffectiveDate -
-------------------------------------------------------------------
-      123 -    CIA - HomeAddress - 123 Cherry Ln -    2010-03-26 -
-      123 -    DMV - HomeAddress - 561 Stoney Rd -    2010-02-15 -
-      123 -    FBI - HomeAddress - 676 Lancas Dr -    2010-03-01 -
-------------------------------------------------------------------

レポート表

Person_Denormalized
----------------------------------------------------------------------------------------
-  Id - Name      - HomeAddress   - HomeAddress_Confidence - HomeAddress_EffectiveDate - 
----------------------------------------------------------------------------------------
- 123 - Joe Smith - 123 Cherry Ln -                  0.713 -                2010-03-26 -
----------------------------------------------------------------------------------------

正規化された設計

Person
-------------------
-  Id - Name      -
-------------------
- 123 - Joe Smith -
-------------------

Person_HomeAddress
------------------------------------------------------
- PersonId - Source - Value         - Effective Date - 
------------------------------------------------------
-      123 -    CIA - 123 Cherry Ln -     2010-03-26 -
-      123 -    DMV - 561 Stoney Rd -     2010-02-15 -
-      123 -    FBI - 676 Lancas Dr -     2010-03-01 -
------------------------------------------------------

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

4

4 に答える 4

6

このスキームでは、まず、ユーザーがあらゆる種類のデータを、その構造に関係なく、将来の使用目的に関係なく保存できるシステムを考え出します。そして、報告書を出す時が来たら、何を手に入れ、それが必要なものとどのように関係しているかを把握しなければなりません。

問題の性質を「このスキームにいる」ことに明確に起因しているため、EAVの問題はEAV自体が原因であるかのように私には思えます。

実際、考えてみてください。「ユーザーがあらゆる種類のデータを保存できるシステム」は、ユーザーが自分の relvar を定義するだけでよいシステムと同等です。しかし、そのシステムのどの部分でユーザーが各属性の制約を定義できるのでしょうか? おっと、EAV クラウドは、データ管理のそれほど重要ではない側面を見逃しているようです...

于 2010-03-26T22:04:16.417 に答える
3

簡単な答え-はい、レポートデータベースはEAVデータモデルからのレポートの問題を解決するための合理的なアプローチです。

私は、エンドユーザーがスキーマとEAVモデルを使用して保存されたデータの両方を使用して、独自のデータモデルを完全に自由に定義できるようにする情報管理ソリューションで何年も作業しました。興味深いことに、この製品は、レポート要件を満たすために使用されるメタスキーマオブジェクトを提供しました（たとえば、オブジェクトナビゲーションを提供するグラフ、投影を実行するビューなど）。これは、エンドユーザーが最初にデータモデルを構築するために使用したのと同じ用語と概念を使用してクエリを自由に定義できることを意味しました。レポートの動作は、基本的に、これらの定義をナビゲートしてデータセットを計算し、その結果をリレーショナルデータであるかのように従来のレポート作成ツールに渡すことでした。

このアプローチの長所の1つは、EAVモデルをユーザーが操作できるものに変換するためにすでに導入されていたのと同じメカニズムを再利用して、レポート機能に適用できることでした。

于 2010-06-14T08:04:26.970 に答える
3

EAV の問題は、EAV 自体が原因ではありません。これは、データ要件が実際に何であるか、およびこれらの要件を満たすためにデータにどのような論理構造が必要かを理解せずに、データベースを設計および構築することが原因です。EAV、およびユーザーが独自のデータを設計できるその他のシステムは、これをひっくり返します。

このスキームでは、まず、ユーザーがあらゆる種類のデータを、その構造に関係なく、将来の使用目的に関係なく保存できるシステムを考え出します。そして、報告書を出す時が来たら、私たちが得たものと、それが必要なものにどのように関係しているかを把握する必要があります.

頑張ってください。

于 2010-03-26T19:39:01.160 に答える
1

EAV に問題はありません。MASSIVE EAV データベースからのクエリにかなりの時間を費やしています。EAV からのレポートが難しい、または不可能であると言う人は、EAV システムの設計が非常に貧弱であるか、EAV システムからクエリを実行する方法を理解していないかのいずれかの問題を抱えています。数回実行すれば、EAV DB からレポート可能な優れたデータを取得するのは非常に簡単です。レポート データベースや特別なものは必要ありません。適切なクエリがいくつかあるだけです。

EAV DB を構築している場合、その設計に多くの時間を費やしている場合、その設計はアプリケーションを作成または破損し、設計が不十分なアプリケーションを修正または処理しようとするのは悪夢です。

于 2012-04-08T02:15:34.237 に答える