MongoDB数据库设计原则
- 首先考虑集合的规模
- 一对很少
比如个人需要保存多个地址，个人关注的话题等。这种情况下使用内嵌文档就很合适 - 一对很多
注意很多的定义: 数百到数千之间。这种情况先使用间接引用比较合适，即通过一个数组保存很多一端的文档id - 一对非常多
通过父级引用来解决，即非常多的那端保存一端的id - 总结
- 确定集合是否为一对多，考虑
多的一端是否需要一个单独的实体 - 确定一对多的程度是
一对很少,一对很多还是一对非常多
-
一对很少且不需要单独访问内嵌内容的情况下使用内嵌的方式 -
一对很多且很多的那一端需要一个单独的实体来描述时，使用数组的方式进行间接引用 -
一对非常多，使用父级引用
- 双向关联
可以让一端和多端同时保存对方的引用，但是如果对应关系发生了变化，那么一端和多端就需要同时更新，这回更耗写资源，也就无法保证操作的原子性。 - 反范式
- 反范式
Many -< One将many端的部分信息冗余到one中，前提是这部分信息必须满足读的比例大于写的比例。 - 反范式
One -< Many冗余one中的数据到many中，同样也应该考虑many端关于该数据的读写比例。 - 总结
- 使用双向引用的前提是需求可以接受无法原子更新的代价，这个代价就是比较耗时的写操作。
- 采用冗余数据的反范式设计时，需要考虑冗余数据的读写比例，读写比高的数据才应该采取反范式话的设计。
- 总结
- 1、优先考虑内嵌，除非有什么迫不得已的原因。
- 2、需要单独访问一个对象，那这个对象就不适合被内嵌到其他对象中。
- 3、数组不应该无限制增长。如果many端有数百个文档对象就不要去内嵌他们可以采用引用ObjectID的方案；如果有数千个文档对象，那么就不要内嵌ObjectID的数组。该采取哪些方案取决于数组的大小。
- 4、在进行反范式设计时请先确认读写比。一个几乎不更改只是读取的字段才适合冗余到其他对象中。
- 5、在mongodb中如何对你的数据建模，取决于你的应用程序如何去访问它们。数据的结构要去适应你的程序的读写场景。
本文章为转载内容，我们尊重原作者对文章享有的著作权。如有内容错误或侵权问题，欢迎原作者联系我们进行内容更正或删除文章。
