【问题标题】:NoSQL/SQL architecture and implementation, 1 collection/table or more?NoSQL/SQL 架构和实现,1 个集合/表或更多?
【发布时间】:2014-10-16 05:18:48
【问题描述】:

您好,我们目前正在 node.js 中构建一个小型公司管理和社交网站。 首先我想提一下我是 mongodb 的新手,其次我想简要说明一些数据库架构实体,以便您可以建议我或提出我应该在 mongodb 数据库上实现的正确架构。

网站特色:

  1. 公司
  2. 用户组
  3. 用户角色
  4. 用户个人资料上的帖子
  5. 关于用户组的帖子
  6. 关于项目的帖子
  7. 用于帖子的 cmets
  8. 用户、组、公司的日历事件
  9. 客户
  10. 供应商
  11. 项目任务
  12. 项目状态
  13. 任务状态
  14. 任务优先级
  15. 标签
  16. 实时聊天、即时消息和存档

这些是网站的一些功能。目前我们使用 mysql 和 orm2(对象关系映射)实现了这一点,但是我们认为 mongodb 会更方便。此外,上述大多数实体都合并在一个表中,使其变得巨大,让我相信这是一种不好的做法。(想象一个存储 100++ 用户、帖子、cmets、事件和任务的即时消息的表...... )

目前我正在考虑具有 4-6 个集合的 mongodb 数据库,将核心实体分开,例如在帖子集合中的相应帖子中合并诸如 cmets 之类的实体。

问题:在单个表下合并实体是否是一种不好的做法(在我们的案例中是在 MySQL 数据库 innodb 中),这会随着时间的推移而变得庞大,这是否也适用于 mongodb 以及在多大程度上适用?我还阅读过一些文章,他们使用关系数据库存储用户角色和组,使用 nosql 数据库存储大量数据。

PS:如果有任何数据库集合/架构建议,我将不胜感激。

【问题讨论】:

    标签: mysql node.js mongodb relational-database nosql


    【解决方案1】:

    合并实体称为非规范化和has pros and cons。通常建议仅在解决实际性能问题时进行非规范化。

    Use a relational database to store relational data。使用平面结构来存储平面数据。句号。不要用卡车参加比赛,即使卡车的马力比赛车大。

    【讨论】:

    • 架构建议将是题外话。
    • 关系型数据库系统在存储关系型数据方面实际上非常糟糕——如果您的实体彼此之间存在大量链接,请考虑切换到图形数据库。与 RDBMS 不同,每个关系都不需要连接,而且遍历效率更高。 ArangoDB 提供了文档存储和图形存储的组合,非常方便。
    猜你喜欢
    • 1970-01-01
    • 2016-08-13
    • 2013-08-23
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2015-04-16
    相关资源
    最近更新 更多