EAVモデルを使用する必要がありますか？

Question

私はeコマースアプリケーション用のデータベース/ドメインを設計していますが、製品の保存方法を見つけるのに苦労しています。

ウェブサイトでは、幅広い製品、ペン、皮ひも、タトゥー、傘などを販売します。これらの各製品は、いくつかの一般的な属性、高さ、幅、長さ、重量などを共有しますが、一部の製品には特別なデータがあります。たとえば、ペンにはさまざまなインクの色があり、先端/ふたやパンフレットは異なるタイプの折り目を持つことができます。これまでのところ、私は20以上の追加属性を考えましたが、これらの属性はウェブサイト上の製品の1％にのみ適用される可能性があります。

したがって、追加のデータを処理するためにEAVモデルを実装することが適切かどうか疑問に思っています。顧客がフロントエンドでサイトを表示している場合、eBayやcarsales.com.auのようなフィルタリングサイドバーがあることに留意してください。 （だから留意して、かなりのクエリがあります）

システムが柔軟性を維持する必要があるため、クラステーブルの継承を実装することは実用的ではないと思います。これは、将来、新しいタイプの製品を使用して、将来より多くの属性がある可能性があるためです。

私が検討したもう1つのことは、NOSQLデータベース（おそらくMongoDB）を使用することですが、これらのタイプのデータベースの経験はほとんどありませんが、それは私の問題を解決しますか？

オプションのレビュー：

1. たくさんの列を備えた単一製品エンティティ
2. 個別の属性エンティティ（EAV）
3. スキーマのない永続性に切り替えます

私は、属性エンティティを備えたプロトタイプを構築して、それがどれほど柔軟性があるかを確認し、パフォーマンスをテストし、クエリがどのように制御できないかをテストしています。

編集：もちろん、私は他のソリューションに開かれています。

Answer 1

素晴らしい質問ですが、もちろん、「真の方法」はありません。 @benvによると、MagentoはEAVモデルを使用しています。私の経験は圧倒的に前向きでしたが、他のユーザーを旅しています。いくつかの考慮事項：

1.パフォーマンス。 EAVは、複雑なマルチテーブル結合が関連する属性をオブジェクトに入力する必要があります。パフォーマンスヒットが発生します。ただし、これは、慎重なキャッシング（クエリキャッシュを含むスタックを介したすべてのレベルで）と非正規化の選択的使用によって軽減できます。 Magentoは、管理者がSKUの数がそれを保証するカテゴリと製品の非正規化モデルを選択できるようにします（一般に数千）。これには、製品データが変更されたときに再インデックス（常に良い！）をトリガーし、「フラット」な非正規化テーブルを更新するオブザーバーが必要です。また、管理者へのプロンプトでスケジュールまたは手動でトリガーすることもできます。

2.サードパーティのユーザーの複雑さこのアプリケーションを他のユーザーが利用できるようにすることを計画している場合、多くの人がEAVが複雑すぎると感じるでしょう。ユーザーフォーラムで多くの声で情報のない虐待に対処することになります（Ref Magento !!）。

3.将来の拡張性とプラグインアーキテクチャ。 拡張性が要因である場合、EAVモデルが実際に独自のものになることは間違いありません。既存のORMおよびコントローラーコードを破るリスクを最小限に抑えながら、新しい属性をモデルに追加することは非常に簡単です。

4.データ型の変更EAVは、属性データタイプを変更することを少し難しくします。最初の設計が将来変化する特定の属性データタイプを必要とする場合（たとえば int に varchar）、それは、新しいデータ型に一致する対応するテーブルにその属性のすべてのレコードを移行する必要があることを意味します。もちろん、純粋主義者はあなたが初めてデザインを手に入れることを示唆しますが、現実は時々侵入します！

5.手動製品の輸入EAVがほとんど不可能にしていることの1つは、SQLおよび/またはPHPMyAdminスタイルのCSV/XMLを使用して、製品（または他のエンティティ）をデータベースにインポートすることです。構造化されたデータを受け入れ、アプリケーションのモデルレイヤーに渡すためにデータベースに持続するインポーターモジュールを記述する必要があります。それはあなたの複雑さを増します。

Answer 2

オープンソースのショッピングカート マゼント EAVデザインを使用して、製品のカスタム属性を許可します。データベーススキーマを確認できます ここ.

Answer 3

Doctrine 2 ORMを使用してDoctrine 2 ORMを詳しく見ることをお勧めします（https://github.com/doctrine/oxm）。さまざまな属性で問題を解決します。もちろん、検索可能なカスタム属性のインデックスを作成する必要がありますが、問題になるとは思いません:)

コミュニティメンバーの数を気にしない場合は、Mongodbも使用できます。