MongoDBの更新パラダイム

Question

MongoDBで私の手を汚くしようとしました。リレーショナルデータベースの背景から来ています。

MongoDBの主な概念の1つは、可能な限り多くのデータをまとめることです。

私は製品とカテゴリを持つアプリケーションを作成し、私は製品をこのように保存想像：

製品コレクション

{ 
    "_id": "30671", //main item ID 
    "department": "Shoes", 
    "category": "Shoes/Women/Pumps", 
    "brand": "Calvin Klein", 
    "thumbnail": "http://cdn.../pump.jpg", 
    "title": "Evening Platform Pumps", 
    "description": "Perfect for a casual night out or a formal event.", 
    "style": "Designer", 
    … 
} 

カテゴリーコレクション

{ 
    "_id": "12356", 
    "name": "Shoes" 
    … 
} 

もしIカテゴリ名を更新すると、巨大な更新プログラムを実行する必要がありますかすべての製品も更新する必要がありますか？あるいは、このシナリオでは、名前の代わりに製品に対してカテゴリIDを実際に格納する方が良いでしょう（リレーショナルデータベースのように）。一般的に

おかげ

Answer 1

それは、リレーショナル・データベースの世界であるようには、「万能サイズ」のアプローチは、MongoDBのではありません。リレーショナル・スキーマ設計では、Categoryを別の表に入れるのは簡単です。実際には、正規化処理中にこれを行うことがほとんどの要件です。

MongoDBでは、スキーマ設計は、ほとんどの経験則や規定された要件よりも、必要なものとユースケースに依存します。もちろん、各選択肢にプラス/マイナスがあります。たとえば：

• あなたはCategoryがはるかに（あるいはまったく）変更されないことをご使用の場合で見つける場合は、安全にProductsコレクションの中に置くことができます。ただし、カテゴリの名前を変更する必要がある場合は、そのカテゴリに属する​​すべての製品を更新する必要があります。
• ユースケースでカテゴリ名を変更する際に柔軟性が必要な場合は、それを別のコレクションに配置し、リレーショナルデザインのように参照することができます。しかし、製品を返すことは、今のところ1回ではなく2回の検索が必要になるため、パフォーマンスが低下する可能性があります（またはルックアップ）。

あなたの例では"category": "Shoes/Women/Pumps"を使用していることに気付きました。 MongoDBでは、ユースケースで許可されている場合、MongoDBを配列に入れることができます。 "category": ["Shoes", "Women", "Pumps"]。このは、フィールドのインデックス作成を容易にします（また、使用例に応じて）。

つまり、MongoDBスキーマ設計には1つの注意点があります。通常、間違ったことは、MongoDBのリレーショナル設計をエフェクトしようとすることです。

また、これらのリンクは参考になりましかもしれません：

• 6 Rules of Thumb for MongoDB Schema Design: Part 1、Part 2、Part 3
• Data Models
• Use Cases