【问题标题】:MongoDB database design, Is redundancies important?MongoDB数据库设计,冗余重要吗?
【发布时间】:2014-05-20 01:05:56
【问题描述】:

我有一个关于 MongoDB 数据库设计的问题。
据我所知(我不确定我是否正确),没有必要使用集合之间的关系。例如,我为用户收集了他们的电子邮件,并且我想将电子邮件模板发送给用户。
我是否应该使用我避免冗余的旧范式并设计 3 个这样的集合:

Users:  ID,Name,Email
Templates: ID,Contents
EmailSent: UserID,TemplateID

或者应该像这样使用 Nosql 范式:

Users:  ID,Name,Email
Templates: ID,Contents
EmailSent: UserID,Contents

区别仅在于电子邮件发送的集合。我根据MongoDB设计架构寻找明确的答案,不是个人意见

【问题讨论】:

  • NoSQL 是一个非常广泛的数据库类型类别。因此,MongoDB 可能有一个特定的答案(也许你应该用 mongdb 标记你的问题),但一般来说 NoSQL 没有。最适合 MongoDB 的东西可能不适用于 Cassandra、Neo4J、CouchBase 等。
  • 我同意 DNA。我冒昧地将问题中的“NoSQL”替换为“MongoDB”,因为这将为您提供更多有用的答案。我还将“Table”替换为“Collection”,因为这是 MongoDB 中的正确术语。

标签: mongodb database-design


【解决方案1】:

在这种特殊情况下,我不会从已发送的电子邮件中引用使用的模板,因为已发送的电子邮件已发送且无法再更改。发送电子邮件后更改模板时,收件人收件箱中已有的电子邮件不会更改。但是,当您在应用程序中查看电子邮件时,它会与新模板一起出现,即使该模板不是在生成电子邮件时处于活动状态的模板。这会给您的用户提供误导性信息。

在更一般的情况下,对于问题嵌入与引用,并没有按惯例解决问题。虽然由于缺少数据库连接,MongoDB 通常更喜欢嵌入而不是引用,但当许多文档嵌入相同数据的副本并且数据发生更改时,嵌入会导致问题。在这种情况下,您要么必须保持数据原样(在某些情况下可能有意义,例如此处),要么在更新嵌入数据时更新所有文档。这将是一项昂贵的操作。

您不会使用引用而不是嵌入进行昂贵的大规模更新操作。但是,这会使检索完整文档的成本更高,因为您必须执行多个后续查询。

您选择哪个选项取决于您预期的常用用例:

  • 当您认为请求子文档是一种频繁的操作而更新子文档是一种罕见的操作时,您会选择嵌入。

  • 当子文档更改非常频繁且请求很少时,引用将是更明智的策略。

【讨论】:

    猜你喜欢
    • 2011-08-19
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2019-12-04
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多