扫码关注官方订阅号
举个例子,有一个用户信息和用户间关系的数据库,如果按照 SQL 的思路,会建立用户信息和用户关系两张表。那么,在 MongoDB 中,是倾向于将用户关系嵌入到用户信号,组成一个单独的文档吗?
ringa_lee
不是这样的。
Collection 的单个 doc 有大小上限,现在是 16MB,这就使得你不可能把所有东西都揉到一个 collection 里。而且如果 collection 结构过于复杂,既会影响查询、更新效率,也会造成维护困难和操作风险。你有尝试过手一抖就把一个 doc 不小心存成 null 的么,反正我做过,要是一个人所有信息都在这个 collection 里面,那感觉一定相当酸爽吧。
一般的原则是:
比如设计一个用户系统,user collection 应该放 name 等常用的信息,也应该放 lastLoginAt 这些仅跟 user 相关的东西,或许应该把用户有哪些访问权限的信息也放进来,但是不要放用户的登录日志这种信息会不断增加的信息。
至于 user 之间的关系是否存在 user collection 则需要讨论。假如仅仅需要存储用户间的关系,记录下好友的 uid 就行,而且好友数量也不太大,几百个最多了,那么我倾向于放在一个 collection 里。如果关系数据本身就比较复杂,或者好友数会上千,那我倾向于拆分。
另外,Mongodb 官方的 数据模型设计范式 很值得一读,推荐去好好看看。
如果业务总是需要查询用户间关系 不如还是把关系独立一个Collection
微信扫码关注PHP中文网服务号
QQ扫码加入技术交流群
Copyright 2014-2026 https://www.php.cn/ All Rights Reserved | php.cn | 湘ICP备2023035733号
PHP学习
技术支持
返回顶部
不是这样的。
Collection 的单个 doc 有大小上限,现在是 16MB,这就使得你不可能把所有东西都揉到一个 collection 里。而且如果 collection 结构过于复杂,既会影响查询、更新效率,也会造成维护困难和操作风险。你有尝试过手一抖就把一个 doc 不小心存成 null 的么,反正我做过,要是一个人所有信息都在这个 collection 里面,那感觉一定相当酸爽吧。
一般的原则是:
比如设计一个用户系统,user collection 应该放 name 等常用的信息,也应该放 lastLoginAt 这些仅跟 user 相关的东西,或许应该把用户有哪些访问权限的信息也放进来,但是不要放用户的登录日志这种信息会不断增加的信息。
至于 user 之间的关系是否存在 user collection 则需要讨论。假如仅仅需要存储用户间的关系,记录下好友的 uid 就行,而且好友数量也不太大,几百个最多了,那么我倾向于放在一个 collection 里。如果关系数据本身就比较复杂,或者好友数会上千,那我倾向于拆分。
另外,Mongodb 官方的 数据模型设计范式 很值得一读,推荐去好好看看。
如果业务总是需要查询用户间关系 不如还是把关系独立一个Collection