MongoDBスキルレス設計 - 利点か混乱？

Question

私はEAV（エンティティ属性値）Webアプリケーションを開発しています。

私はmongoを使用したい主な理由は、それはschemalessです。つまり、不要なフィールドを持たずに "color"属性を持つ車を見つけるのはとても簡単です。ここで

を実装するために、文書構造の簡単な例です：

ウェアコンピュータカテゴリから：

{ 
    name: "Audi Q7", 
    category: 2, 
    properties:{ 
     price:30000, 
     color:"red", 
     hp:200 
     ... 
    } 

：

{ 
    name: "Core i7", 
    category: 1, 
    properties:{ 
     price:300, 
     vendor: "Intel", 
     ... 
    } 
    } 

は、一方の属性のそれ自身のセットを持つ自動車カテゴリからウェアがあります

}

しかし、もし私が100 catego私のDBは100種類の文書を保存します（構造によって）。 MongoDBのドキュメントによれば、ドキュメントはスキーマレスである可能性があると言われていますが、ドキュメントの構造はそれほど大きくないか同じであることをお勧めします。

私の質問です：さまざまな構造文書がたくさんあるのは非常に悪い習慣ですか？

Answer 1

"良い"または "悪い"は非常に主観的です。それが害より多くの利益をもたらすならば、それは良いことです。それ以外の場合は、おそらくそうではありません。

MongoDBはスキーマレスなので、ここでは、少なくともはには、（リレーショナルDBではなく）構造が異なる多数のドキュメントがあります。この事実自体は中立です。それはあなたのアプリケーションのためにそれを良くするか悪くするかのあなたの使用です。

Answer 2

「製品」カタログのようなものについては、ドキュメントごとに異なる構造を持つことは完全に合理的です。実際には、トップレベルの構造がまったく異なるわけではありません。各アイテムのプロパティには、配列内の要素が異なります。