Node.js Mongodb数据模型战略指导/建议

我只是从node和mongodb开始，试图了解如何最好地构造数据（来自sql的生命周期）

因此，我最终得到了一个基本上是嵌入式的数据结构，我相信这些关系是合乎逻辑的，但在我走得太远之前，我希望得到一些外部反馈

下面是我提议的新mongodb数据模型：

user
    name (string)
    email (string)
    avatar (string)
    password (string)
    newsletter (binary)

account
    admins
        user (objectId)
    name (string)
    logo (string)
    sub (number)
    stripe (string)
    property
        users
            user (objectId)
            party (number)
            role (number)
            admin (binary)
        name (string)
        ecd (date)
        complete (binary)
        activity
            description (string)
            user (objectId)
            time (date)
        task_group
            position (number)
            name (string)
            task
                assinged
                    user (objectId)
                    complete (binary)
                name (string)
                description (string)
                due (date)
                visibility (number)
                comment
                    user (objectId)
                    time (date)
                    comment (string)

以前（我正在重建一个现有的sql应用程序），有很多表纯粹是用来连接数据的，例如，

account\u link

用来连接用户和帐户（多对多）等。现在已经嵌入了这些表，这使得结构更加直观。考虑到嵌入式数据只需要在其父数据的上下文中访问，我认为这是一种方法

我担心的是，某些子文档将变得相当大。我是否需要担心子文档中包含多少数据？或者我应该像对待表格一样对待子文档吗？i、 e.如果发现每个

任务组

包含400000个任务，该不必要的“膨胀”属性是否会？您是否纯粹出于实际/性能原因将这些内容拆分并创建“链接表”？或者我只是太过拘泥于sql思维，以至于感觉这是错误的

更新

鉴于收到的建议和参考，我相信我已经制作了一个更合适的设计，尽管正如其他地方所指出的，它更多的是一门艺术而不是一门科学。欢迎反馈

重要考虑：

我不会重新撰写链接的博客文章，但总结如下：

• 如果基数是一对几，并且不需要访问父对象上下文之外的嵌入对象，则嵌入N侧
• 如果基数为一对多，或者如果N侧对象因任何原因应独立，则使用N侧对象的引用数组
• 如果基数为1到squillions，则使用对N侧对象中一侧的引用

我还考虑了其中一个答案中提到的增长/文档大小一致性

USER
    name (string)
    email (string)
    avatar (string)
    password (string)
    newsletter (binary)

ACCOUNT
    admins (USER reference array)
    name (string)
    logo (string)
    sub (number)
    stripe (string)
    properties (PROPERTY reference array)

PROPERTY
    name (string)
    ecd (date)
    complete (binary)
    users
        user (USER objectId)
        party (number)
        role (number)
        admin (binary)
    activity
        description (string)
        time (date)
    task_groups (TASK_GROUP reference array)

TASK_GROUPS
    property (PROPERTY objectId)
    position (number)
    name (string)
    task
        assigned
            user (USER objectId)
            complete (binary)
        name (string)
        description (string)
        due (date)
        visibility (number)
        comment
            user (USER objectId)
            time (date)
            comment (string)

以下是关于

1） 与客户建立一对一关系模型 2） 与嵌入式文档建立一对多关系模型 3） 与文档引用建立一对多关系模型

阅读所有三段

我只想说，当嵌入式文档变得相当大时，您必须使用未嵌入的文档引用

在我解释之前，先看这些图片：

当文档增长时，收藏中的每个文档都有自己的位置和空间，而在收藏的和处没有足够的空间，留下了自由空间 例如，您有post collection，它有嵌入的collection注释

post {
  _id:ObjectId('101');
  comments:[{author:'john',text:'some text'},{author:'mike',text:'some text'}]
}

当您只能添加一个、两个或三个注释（不是很多）时，此模型非常有用，但当您可以根据需要推送注释时，您必须编写带有引用的文档 将有帖子收集和评论收集

收款后文件：

{
_id:ObjectId('101')
}

  {
    _id:ObjectId('10001'),
    _postId:ObjectId('101'),//references to post collection document!
    text:'some text',
    author:'john'
    }

意见收集文件：

{
_id:ObjectId('101')
}

  {
    _id:ObjectId('10001'),
    _postId:ObjectId('101'),//references to post collection document!
    text:'some text',
    author:'john'
    }

---

我甚至可以将任务从任务组中分离出来，使任务组成为任务的一个属性。您可能希望查询组中的每个任务。只要你知道它属于哪个任务，你就可以做

但是，您可能也想查找特定的任务，但有关该任务所属的一个或多个组的信息可能仍然与该任务相关。如果您以这种方式将任务嵌入到任务组中，那么您的应用程序将不得不找出该任务可能属于哪个类别/组。也许这些组的功能更像一个过滤器，在这些组中查找具有此描述的任务

当您考虑如何查询时，您可能希望对这些结构执行的不同查询变得更加明显。下一步是查询和建立索引模型。如果在嵌入文档上有一个索引，那么它可能是一个与原始文档相关的独立模型。但这也取决于嵌入文档在多大程度上依赖于其上方结构中的属性

tl；博士

---

我发现一个常见的经验法则是，如果你对嵌入的文档进行大量的读取和很少的写入，那么嵌入是可以的。通过大量的书写和阅读，你将想要分离嵌入的本质

Hi@kaxi1993-我已经阅读了文档，了解了不同的方法，这更多的是关于文档没有很好涵盖的特定用例（请随意引用您认为我可能遗漏的内容）。“我只想说，当嵌入式文档变得相当大时，您必须使用未嵌入的文档引用”……这就是我要问的，什么是“相当大”？那么在那个阶段嵌入文档会有什么后果呢？你读过吗？我想我没有读过-谢谢，我现在就看一遍！实际上，这是一个非常有用的帖子！似乎没有人讨论多层次的关系（如我的示例中），但自然会应用相同的规则，只是以稍微复杂一点的方式。我会发布我的更新设计一旦定稿。谢谢你的解释！因此，从本质上讲，您所说的是，嵌入文档只有在子文档中有少量条目时才是真正合适的（任何最佳实践上限？取决于其他因素？）。对于我的用例来说，这可能不是一个问题，但我想更好地理解上限和限制。没有上限，它取决于每个文档的大小，如果需要选择单个文档，需要对查询进行更多控制，或者有大量文档，单独的集合是很好的。一般来说，如果你有很多“评论”或者他们有大量的文本，最好是单独的集合。单独的集合易于插入，嵌入的文档易于选择。这些因素的总和仅取决于