MongoDB----数据结构---数据结构优化修改

look_w

在使用MongoDB开发的过程中，因为它的方便性，很多数据都使用了内嵌文档的形式保存。


但是这样的结构在后期的开发过程中造成了很多问题。


深刻的体会到了，MongoDB可以不设计集合的结构和数据类型即可使用，但不代表它不需要数据结构设计。


一个好的系统运作，肯定需要对MongoDB的数据结构进行合理的设计才能高效运行。


当然，我也不建议在业务初期就进行严格的数据结构设计，因为在开发初期业务变化快。可以在业务运行一段时间稳定，熟悉业务场景之后对MongoDB的数据结构进行优化调整。



主要考虑以下几个方面:


不要嵌套太深

不要嵌套太深，否则读取更新删除起来会很复杂,最多一两层。



业务类型的字段不要内嵌到基本实体中,而是使用关联

比如我们有一个商品实体，我们想要给它增加一种图表展示。

图表展示就是我们的业务。
这种时候最好不要把图表数据内嵌到基本实体中，随着业务展示方式增多这样会让商品基本实体越来越混乱，而且不好清理。
修改也复杂，一条业务信息有变动，包含它的基本实体都需要修改。
因为业务是经常变动的，有可能过一段时间就不用这种展示方式了。
所以最好是把业务信息新建实体。与基本实体建立关联。这样好管理和清除。
同时业务的操作不会影响到基本实体的信息。



如何合理建立关联

关联有四种方式:

它们都能解决业务实体变动所有包含它的基本实体都需要修改的问题。


一、基本实体引用业务实体
好处: 读取方便，与内嵌在基本实体中的使用方式一样get即可。
坏处:没有解决基本实体越来越大，越来越混乱的问题，删除业务实体麻烦。


二、基本实体保存业务实体ID
好处: 缓解基本实体越来越大，越来越混乱的情况。
坏处: 需要读取两次，删除业务实体麻烦。



三、业务实体保存基本实体ID
好处:删除清理方便，删除业务实体后，关联关系也随着删除
坏处:需要读取两次




四、新建关联表
好处: 基本实体，业务实体数据清晰，不会变大。
坏处:需要读取3次，删除业务实体麻烦。



关联关系保存在哪个实体中，需要考虑数量多少的问题，一般是被包含的数量少的 保存 在被包含数量多的 实体里。
比如我有一个商品实体和一个版本实体。它们需要建立关联。
因为每个商品只可能属于几个版本，所以关联信息保存在商品实体中只需要保存几个版本的值即可。
但是每个版本可能含有成千上万个商品，所以关联信息保存在版本实体中，需要保存成千上万个商品的值。应该避免这样的关联。
或者新建一个关联表，关联关系单独存放，这样的数据结构最清晰，但是读取修改删除都稍微麻烦一些。