NoSQL/SQL 架构和实现，1 个集合/表或更多？

Posted 2023-03-12

【中文标题】NoSQL/SQL 架构和实现，1 个集合/表或更多？

【英文标题】：NoSQL/SQL architecture and implementation, 1 collection/table or more?

【发布时间】：2014-10-16 05:18:48

【问题描述】：

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

网站特色：

公司 用户组 用户角色 用户个人资料上的帖子 关于用户组的帖子 关于项目的帖子 用于帖子的 cmets 用户、组、公司的日历事件 客户 供应商 项目任务 项目状态 任务状态 任务优先级 标签 实时聊天、即时消息和存档

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

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

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

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

【参考方案1】：

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

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

【讨论】：

架构建议将是题外话。

关系型数据库系统在存储关系型数据方面实际上非常糟糕——如果您的实体彼此之间存在大量链接，请考虑切换到图形数据库。与 RDBMS 不同，每个关系都不需要连接，而且遍历效率更高。 ArangoDB 提供了文档存储和图形存储的组合，非常方便。