私は仮定します：
{
g: [
{ _id: ObjectId(), property: '' },
// next
]
}
この質問の構造のタイプ。
通常ではありません。 _id sはエンティティの一意の識別子です。そのため、_idを追加する場合は サブドキュメントオブジェクト内では、データが適切に正規化されていない可能性があり、スキーマ設計内の根本的な欠陥の兆候である可能性があります。
サブドキュメントは、そのドキュメントの繰り返しデータ、つまりアドレスやユーザーなどを含むように設計されています。
_idと言われています 追加するのは必ずしも悪いことではありません。先ほどアドレスで述べた例を見てください。ショッピングカートシステムがあり、（何らかの理由で）住所を注文書に複製しなかった場合、_idを使用するとします。 または、そのサブドキュメントを取得するためのその他の識別子。
また、ドキュメントのリンクも考慮する必要があります。その_idの場合 別のドキュメントを記述し、プロパティはそのリンクされたドキュメントに関連するそのドキュメントのカスタム属性であり、それでも問題ありません。
ObjectId はまだかなり大きいので、小さくて一意性の低いIDを考慮したり、_idを使用しないことを考慮に入れる必要があります。 サブドキュメントの場合はまったく。
インデックスの場合、標準の_idと実際には何の違いもありません。 ドキュメント自体のフィールドとフィールド全体の一意のインデックスは、コレクション全体で機能する必要があります（シナリオに依存し、クエリをテストします）。
注意：MongoDBは_idを追加しません あなたのためにサブドキュメントに。