0

私はEAV（entity-attribute-value）webアプリケーションを開発してきました。

私がmongoを使用したい主な理由は、スキーマがないことです。つまり、不要なフィールドがなくても、「color」属性を持つ車を簡単に見つけることができます。

実装するドキュメント構造の短い例を次に示します。

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

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

一方、独自の属性セットを持つ自動車カテゴリのウェアがあります。

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

}

しかし、100個のカテゴリがある場合、データベースには100個の異なるドキュメントが格納されます（構造によって）。MongoDBのドキュメントによると、そのドキュメントはスキーマレスである可能性がありますが、ドキュメントの構造を同じにすることをお勧めします。

私の質問は：多くの異なる構造文書を持つことは非常に悪い習慣ですか？

4

2 に答える 2

4

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

MongoDB はスキーマレスであるため、ここでは少なくとも、(リレーショナル DB とは対照的に) 構造が異なる大量のドキュメントを作成できます。この事実自体は中立です。アプリケーションにとって良いか悪いかは、あなたの使い方次第です。

于 2012-05-01T11:19:43.773 に答える
1

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

于 2012-05-01T11:49:49.963 に答える