MongoDBは私の業界に適していますか？

Question

私はプロモーション製品業界で働いています。我々はあなたが印刷、刺繍、彫刻、または他のどのような方法でもカスタマイズできるものをほとんど販売しています。人気のある製品はペン、マグカップ、シャツ、キャップなどです。私たちは多種多様な製品を持っているため、可能なすべての製品オプション、装飾オプション、および関連するすべての追加費用を含め、これらの製品に関する情報を保存することは非常に複雑になります。そう多くは、多くの試みがありましたが、データのマッサージをある程度しなくても、データをアルゴリズムに基づいて電子商取引ストアに変換できるような方法で、業界の製品データを提供することはできませんでした。この情報をリレーショナルデータベースに適切に保存することは、ほとんど不可能に近いようです。 MongoDBなどのNoSQLオプションを使用すると、MySQLなどのRDBMSよりも製品情報を保存して操作する方が簡単に情報をモデル化することができますか？私が働く会社は100歳以上で、長年AS400でDB2を使用しています。非リレーショナルDBソリューションを利用するように説得するには、いくつかの理由が必要です。

---

業界で使用される一般的な例の生成物は、バレル20上のカラーオプションをそれぞれ有しており、色をトリムビックclicクリックSTICペンです。シルクスクリーン装飾のためにさらに多くの色を選択できます。次に、使用するインクの種類に関する追加オプションを選択できます。パッケージングには複数のオプションがあります。選択した後は、ラッシュ処理のための追加オプションがあります。これらのオプションには、注文するペンの数や装飾品の色数に基づいて追加料金が発生する場合もあります。価格は通常、数量に基づいているため、250ペンスの注文は1000ペンスよりも多くなります。同様に、250ペンス以上のペーストでは、1000ペンスで注文すると安くなります。

Answer 1

これは銀色の弾丸の質問のリングを持っています。

あなたは本質的に複雑なビジネスドメインを持っています。データを格納する別の方法がその複雑さに影響を与えることは明らかではありません。リレーショナルデータではなくドキュメントを格納すると、顧客が250以上の注文をした場合、ペンを0.02ドル安くすることはおそらく簡単になりません。

私はビジネスドメインに焦点を当て、ストレージメカニズムについてあまり心配しないことをお勧めします。私はDomain Driven Designの大きなファンです。これはそのアプローチの完璧なケースのように聞こえます。

Answer 2

文書データベースを使用しても問題は完全には解決されませんが、おそらく役に立ちます。

ドキュメントが製品で利用可能なオプションとその製品の注文を表す場合、ほとんどの場合、ドキュメント全体にアクセスすることになります。これはSQLではできませんが、ドキュメントデータベース。文書の構造は柔軟であるため、データベース内の変更を行わずに、特定のオプションまたは規則を定義する複雑なタイプとして文書内のオブジェクトを定義することは比較的容易です。

しかし、これはデータに役立ちます。実際の問題はUI側にあります。 2つのドキュメントは一緒に注文フォームに直接マップされますが、オプション/ルールを定義するために使用する方法は、非常に複雑な設定ページで終わることになります。

Answer 3

はい、MongoDBが必要です。厳密な文書構造を持たないため、必要な一連のモデルを作成し、必要な順序と組み合わせで商品ページに埋め込むことができます。実際には、実際のモデルフィールドを直接記述することなくこのデータを処理することが可能です。したがって、私はRailsアプリケーションがまったく知らないフィールドを使用できます。

また、MongoDBは、レプリケーションとシャーディングの設定が非常に簡単です。また、GridFS仮想ファイルシステムをサポートしているため、製品のイメージを記述したドキュメントでイメージを保存し、単一のオブジェクトとして簡単に操作できます。

あなたは間違いなくそれを試してください。

UPD：とにかく、RDBMSを財務データや売上分析のためのレポートのグループ化などのために維持するとよいでしょう。 NoSQLベースはあまりよくありません。