常にではありませんが、死ぬまで正規化するとパフォーマンスが低下しますが、SQLと同じ正規化をMongoDBに個人的に適用しないのは事実です。
正規化された形式を知っている場合（ http://en.wikipedia.org/wiki/Database_normalization ）MongoDBを1NFに移行してから、再び非正規化に戻すと考えるのが好きです。
そうそう、そうです。データが間違って複製されている場合、更新は面倒です。
例を挙げましょう：category およびproduct 2つの別個のエンティティになり、それを否定することはできません。これらの2つのエンティティは正規化されています（productの繰り返しデータ categoryから槍で打たれました ）。別の考え方は次のとおりです。すべての製品は1つのカテゴリにのみ存在するのでしょうか？
したがって、トップレベルのエンティティでは、ご覧のとおり、同じルールが比較的適用され、1NFはMongoDBに簡単に適用されます。
もちろん、複製の前では、各カテゴリ内で各製品を個別に保存することは望まないので（上記の質問には「いいえ」と答えました）、当然、カテゴリと製品を分離する必要があります。
通常、ここでは、中間の正規化されたテーブルと多対多の関係があります。これが非正規化の出番です。カテゴリには、そのカテゴリに固有の製品のリストが含まれるため、多対多のリレーショナルテーブルをリストとしてカテゴリ行に非正規化できます。 （またはその逆で製品行に）。そのリストはそのカテゴリに固有であるため（おそらく）、これによって重複が生成されることはありません。これはもちろん、カテゴリまたは製品にリスト_idが含まれることを意味します オブジェクト自体ではなく、関連する行のs。
主に最適化やJOINがない場合の回避策のために、複製が必要になる場合があります。このルールは、十分な規模のサイトを作成したことがある場合はSQLにも適用されます。
複製の一般的な使用シナリオは、Facebookの投稿の共有やコメントなどの統計の集計フィールドであり、その投稿の最新の5つのコメントでさえも投稿行に複製される可能性があります。
したがって、これはスキーマ設計を無視する場合ではなく、MongoDBの特性に合わせてスキーマ設計を調整する場合です。通常、これを行うと、当然、優れたスキーマを設計することがわかります。
追加のリファレンスとして、ここで参照できます： http://docs.mongodb.org/手動/コア/データモデリング