MongoDB是否拆分菜单、分类、菜品为独立集合？附收藏需求

Great question—let’s break this down into two clear parts: whether splitting your collections makes sense for your use case, and how to handle unique item IDs if you stick with the embedded structure.

It depends on your specific workflow and query patterns, but let’s weigh the pros and cons relative to your favorite feature:

• Stick with embedded documents if:

  • Your menu structure is relatively static (you rarely add/remove/update individual items without editing the whole menu)
  • Most queries need the full menu context (e.g., users view entire menus rather than isolated items)
  • You want the performance benefit of single-document reads (fetching a menu pulls all sections and items in one go)

• Split into separate collections if:

  • You frequently need to query, update, or delete individual items independently (e.g., changing a dish’s price without touching the rest of the menu)
  • Items might be reused across multiple menus (though that doesn’t seem to be your case here)
  • Your favorite feature requires frequent lookups of item details (e.g., showing a user’s saved favorites without loading the entire parent menu) — splitting makes this faster, as you can query the items collection directly by _id instead of filtering through nested arrays.

For your favorite functionality, splitting does add some convenience, but it’s not strictly required if your menu structure stays stable.

Right now, your items don’t have their own _id fields, so you’ve got a few options:

1. Add unique _id fields to each item (Recommended) #

This is the most reliable approach. You can update your existing menu documents to inject unique ObjectIds (or custom unique identifiers) into every item using an aggregation pipeline update:

db.menus.updateMany(
  {},
  [
    {
      $set: {
        "sections": {
          $map: {
            input: "$sections",
            as: "section",
            in: {
              name: "$$section.name",
              items: {
                $map: {
                  input: "$$section.items",
                  as: "item",
                  in: {
                    _id: ObjectId(),
                    name: "$$item.name",
                    description: "$$item.description",
                    price: "$$item.price"
                  }
                }
              }
            }
          }
        }
      }
    }
  ]
)

Once each item has its own _id, your favorites collection can simply store user_id and item_id, and you can fetch item details with a query that filters the nested arrays (or use aggregation to unwind and match).

2. Use a composite identifier (Less reliable) #

If you can’t modify existing documents, you can create a unique key using a combination of the parent menu’s _id, the section’s name/index, and the item’s name/index. For example, your favorites collection might store:

{ user_id: ObjectId("..."), menu_id: ObjectId("5c73cc96c2fb92219aeb476a"), section_name: "Small Plates", item_name: "Kimbop" }

But this has big downsides: if you ever rename a section or item, or reorder items in the array, the composite key breaks. It’s a temporary workaround at best.

3. Aggregate to locate items (For one-off queries) #

To fetch a specific item without an _id, you can use $unwind to flatten the nested arrays and then match the item:

db.menus.aggregate([
  { $match: { _id: ObjectId("5c73cc96c2fb92219aeb476a") } },
  { $unwind: "$sections" },
  { $unwind: "$sections.items" },
  { $match: { "sections.items.name": "Kimbop" } },
  { $project: { item: "$sections.items", _id: 0 } }
])

But this isn’t ideal for your favorites feature, as you’d need to store enough metadata to replicate this query every time you want to load a user’s saved items.

内容的提问来源于stack exchange，提问作者Abhilash Lohar