6

アプリケーションのデータ モデルに対する健全なアプローチを探しています。ほとんどのスレッドは e コマース製品に焦点を当てていますが、私のシナリオは多少異なります。

目標は、顧客から受け取ったアイテムを保管し、それらについて報告することです。最初のレポートは単純なリスト (アイテムとそのキーと値のペア) になりますが、コレクション全体に対する将来のクエリに備えたいので、EAV が適切なアプローチであるかどうかはわかりません。

各アイテムは（繰り返し）タイプであり、各アイテムには柔軟な量のキーと値のペアがあります。約 15 種類のアイテムがあり、急速に成長する可能性はあまりありません。

キーと値のペアの数は少なく、4 ～ 20 であり、(要件ごとに)アイテムの種類ではなく、アイテムが属する顧客に基づいています。

明確にするために、顧客は私にアイテムの状態を保存することを望んでいるかもしれませんが、別の顧客は色または交換IDを保存することを望んでいるかもしれません. それは本当に依存します。したがって、各項目タイプがその顧客のすべてのキー/値をとにかく取得するため、セットに NULL 値が含まれる可能性が非常に高くなります。これにより、単一テーブルの継承(NULL 値を使用) は許容できると思いますが、顧客が目的のキーの名前を決定するため、何らかのマッピングを使用して、field_1 field_2 などにする必要があります。正しくないと思われるのはどれですか?

顧客アイテム (およびそのキー/値) のコレクションは、通常 20 を超えて 500 未満であるため、顧客ごとのデータ セットは確かに膨大ではありません。

おそらく、MySQL でアプリケーション自体 (顧客とその目的のフィールドを作成する) の (セミ) EAV に移行するのが良いアプローチですが、実際に収集されたアイテム レコードを「ドキュメント」として NoSQL データベース (Redis など) に移動して、さらに詳しく調べることができます。処理？

それとも、RDBMS で解決できる/解決すべきことを複雑にしすぎているのでしょうか?

私はまた、このhttp://backchannel.org/blog/friendfeed-schemaless-mysqlに出くわしました。これは解決策のようですが、私の数が非常に少ないためわかりません。

4

1 に答える 1

12

リストされた 3 つのアプローチすべてでプロジェクトを実行したので、厳密で迅速な方向性を示すことができるかどうかはわかりませんが、前進して正しいアプローチを選択するためのアドバイスを提供できます。

チップ：

  1. 可能であれば、テクノロジーを混在させないようにしてください。個人的な経験から、これは非常に難しいと感じました。また、スケーリングが必要な大規模なサイトでは、アーキテクチャをシンプルに保つことが常に言及されていることがよくあります。彼らは、MySQL と MongoDB のようなものの混合物から始めて、物事を単純にするためだけに MongoDB を捨てます。

  2. あなたの質問は、少し分析麻痺に苦しんでいるようです。「私は XYZ を行うことができましたが、それは ABC が不可能であることを意味します。」システムに関するいくつかのポイント/事実を修正してから、プロトタイプの構築を開始することをお勧めします。あなたは良いアイデアを持っているように見えますが、それが実際にどれだけ優れているかは、構築を開始するまでわかりません。

  3. すべての決定には結果があることを認識してください。ソリューションの最初の 80% は、おそらくかなり迅速かつ簡単です。最後の 20% は妥協で構成され、かなり見苦しいものになる可能性があります。そのための準備をして、大丈夫です。

  4. 私の経験からすると、ドキュメント データベース (NoSQL) のアプローチにはまだ少しリスクがあります。堅実な 1 年間のドキュメント開発を行った結果、最も困難だったのはデータのモデル化でした。その道をたどりたい場合は、データモデリングを必ず勉強してください。それはあなたに多くの苦痛を救います。

于 2013-06-03T16:49:50.367 に答える