猫鼬子文档与嵌套模式

我对在主模式中使用子文档和更深层的优缺点感到好奇：

var subDoc = new Schema({
  name: String
});

var mainDoc = new Schema({
  names: [subDoc]
});

要么

var mainDoc = new Schema({
  names: [{
    name: String
 }]
});

我目前在各处使用子文档，但是我主要想知道性能或查询我可能遇到的问题。

根据文档，它是完全一样的。但是，使用Schema也会添加一个_id字段（只要您没有禁用该字段），并且大概会使用更多资源来跟踪子文档。

备用声明语法

v3中的新增功能如果不需要访问子文档架构实例，则还可以通过简单地传递对象文字来声明子文档[...]

如果您有在模型的各个部分中重复使用的架构，则为子文档定义单个架构可能会很有用，这样您就不必重复自己了。

如果嵌入文档是静态文档，或者由于性能影响不超过几百个，则应使用嵌入文档。我已经解决了一段时间了。最近，作为MongoDB解决方案架构师的Asya Kamsky写了一篇有关“使用子文档”的文章。

我希望这对寻求解决方案或最佳实践的人有所帮助。

原始帖子位于http://askasya.com/post/largeembeddedarrays。您可以在https://stackoverflow.com/users/431012/asya-kamsky上找到她的stackoverflow个人资料

首先，我们必须考虑为什么要这样做。通常，我建议人们在获取此文档时嵌入他们一直想要取回的东西。不利的一面是，您不想将不需要的内容嵌入文档中。

如果您将我执行的活动嵌入文档中，那么起初效果会很好，因为我所有的活动都在那里，只需阅读一遍，您就可以取回您可能想要显示的所有内容：“您最近在此处单击了此处是您的最后两个评论”，但是六个月后会发生什么，我不在乎我很久以前所做的事情，除非我专门去寻找一些旧活动，否则您不想向我展示它们？

首先，您最终将返回越来越大的文档，并关心其中越来越少的部分。但是您可以使用投影仅返回一些数组，真正的痛苦是磁盘上的文档将变得更大，即使您只打算将部分文档返回给最终用户，它仍将被全部读取，但是由于只要我处于活动状态，我的活动就不会停止，因此该文档将继续增长。

最明显的问题是，最终您将达到16MB的文档限制，但这根本不是您应该关注的问题。不断增长的文档每次必须将其重新放置在磁盘上时，都会招致越来越高的成本，即使您采取措施减轻碎片的影响，您的写入总体上也将不必要地长，从而影响整个应用程序的整体性能。

您还可以做一件事，那将完全破坏应用程序的性能，并且将这个不断增加的数组编入索引。这意味着每次重新定位具有此数组的文档时，需要更新的索引条目的数量都与该文档中的索引值的数量成正比，并且数组越大，该数量将越大是。

我不希望这使您害怕在数组非常适合数据模型时使用它们-它们是文档数据库数据模型的强大功能，但是像所有强大的工具一样，需要在正确的情况下使用它并且应谨慎使用。

基本上，创建一个变量nestedDov并将其放在此处name: [nestedDov]

简单版本：

var nestedDoc = new Schema({
  name: String
});

var mainDoc = new Schema({
  names: [nestedDoc]
});

JSON范例

{
    "_id" : ObjectId("57c88bf5818e70007dc72e85"),
    "name" : "Corinthia Hotel Budapest",
    "stars" : 5,
    "description" : "The 5-star Corinthia Hotel Budapest on the Grand Boulevard offers free access to its Royal Spa",
    "photos" : [
        "/photos/hotel/corinthiahotelbudapest/1.jpg",
        "/photos/hotel/corinthiahotelbudapest/2.jpg"
    ],
    "currency" : "HUF",
    "rooms" : [
        {
            "type" : "Superior Double or Twin Room",
            "number" : 20,
            "description" : "These are some great rooms",
            "photos" : [
                "/photos/room/corinthiahotelbudapest/2.jpg",
                "/photos/room/corinthiahotelbudapest/5.jpg"
            ],
            "price" : 73000
        },
        {
            "type" : "Deluxe Double Room",
            "number" : 50,
            "description" : "These are amazing rooms",
            "photos" : [
                "/photos/room/corinthiahotelbudapest/4.jpg",
                "/photos/room/corinthiahotelbudapest/6.jpg"
            ],
            "price" : 92000
        },
        {
            "type" : "Executive Double Room",
            "number" : 25,
            "description" : "These are amazing rooms",
            "photos" : [
                "/photos/room/corinthiahotelbudapest/4.jpg",
                "/photos/room/corinthiahotelbudapest/6.jpg"
            ],
            "price" : 112000
        }
    ],
    "reviews" : [
        {
            "name" : "Tamas",
            "id" : "/user/tamas.json",
            "review" : "Great hotel",
            "rating" : 4
        }
    ],
    "services" : [
        "Room service",
        "Airport shuttle (surcharge)",
        "24-hour front desk",
        "Currency exchange",
        "Tour desk"
    ]
}

例：

我认为这是在SO上的多个帖子中处理的。

一些：

• MongoDB关系：嵌入还是引用？
• 我应该如何在MongoDB中实现此架构？
• MongoDB Schema Design-很多小文件还是更少的大文件？

最大的关键是这里没有一个单一的答案，只有一系列相当复杂的权衡。

两者之间有一些区别：

• 使用嵌套模式有助于验证。

• 嵌套模式可以在其他模式中重用。

• 嵌套模式将'_id'字段添加到子文档中，除非您使用了“ _id：false”