在MONGODB 的使用中，对开发模型设计是有更高的要求的，这对于MONGODB 的后期运行的性能有非常总要的意义。 基于MONGODB 的使用中的关系分为
1 VS 1
1 VS N
N VS N
在设计中设计的步骤主要分为 概念设计阶段，逻辑设计阶段，物理设计阶段，在设计阶段也分为对于数据有几个定义，一个数据包含，实体，属性，关系几个部分。
一个数据如 一个名字 Mongodb 这就是一个实体， 而属性就是这个MONGODB 本身代表了一个数据库，属性是定义这个实体具体的用处，关系本身代表了 MongoDB 与其他实体的关系，如MONGODB 和数据库之间的关系是属于的关系， MONGODB 与 REDIS 之间的关系是都是NOSQL数据库，关系本身是属性本身与其他属性之间的关系表达。
这里具体到MONGODB 的schema 设计中会牵扯到关系本身，这也就是上面提出的属性和属性之间的 1 vs 1, 1vs n, n vs n.
一个错误的概念就是MONGODB 属于无 schema 的设计模式，只要将数据JSON化，全部存在DOCUMENT 中就可以了。这是一个非常糟糕的想法。
这里有两个实际的想法，1 保证数据提取时的高性能 2 应用开发中数据的写入或更新更加方便。
主要基于以下几个思考
1 业务，以及业务数据，需要对业务的数据
2 数据的写入，更新，读取之间的侧重
3 数据的形成方式，嵌套，数组，关联
1 基于MONGODB 的使用中，最重要的第一步就是了解业务，举例一个用餐的评价系统，来记录用餐客户对于产品的感受。这里有两点
1 核心是客户，所有的评价针对客户消费的每一个菜品，另外客户如果是多个人对菜品进行消费，一桌3个人，是否都可以针对菜品进行评价。等等这些都是需要和产品分析和沟通后，获知的。一般来说对于菜品的评价，都是通过移动端（手机，或移动设备）进行的评价，评价一般只有一人，就是持有移动设备的人，而对于菜品的来说，评价人针对菜品的关系就是一对多的关系，并且在评价完毕后，一般我们只允许客户删除评论，不运行进行修改，关于评论可以在删除后，在评论。
基于以上的分析，得出
1 逻辑关系是 客户 与 菜品之间的关系，关系是客户与消费了的菜品之间建立关系。
2 客户与菜品之间的关系是一对多的关系。
3 评论是读多写少，并且一般来说评论很少存在修改和删除的情况。
4 评论本身不存在金融属性，对于时效性和准确性并未有明确严格的要求。
基于以上的信息，这里大概设计一个MONGODB schema 来完成上面的需求
1 在餐饮店和客户之间是关联的关系，餐饮店与客户之间是多对多的关系
基于上面的基础
｛“_id”: object_id
“customer_id”: 23978372,
“customer_name”: Yeta,
“comment”:[
｛
“菜品1”：“非常糟糕，一点都不好吃”
｝，
｛“菜品2”：“还可以，就是不热”
｝]，
"service_time": "2021-02-09 12:34:09"}｝
或者设计成
｛“_id”: object_id
“customer_id”: 23978372,
“customer_name”: Yeta,
“菜品1”：“非常糟糕，一点都不好吃”，
"service_time": "2021-02-09 12:34:09"}｝
｛“_id”: object_id
“customer_id”: 23978372,
“customer_name”: Yeta,
“菜品2”：“还凑活”，
"service_time": "2021-02-09 12:34}｝
这两种都是针对上面的实际，而还是根据业务来思考，一个客人一般对于菜品的评价都是对特别印象深刻的进行评价，而不会对于每个菜品都进行评价，很少人这么闲有这么多时间，那么第二个方式是可以被作为设计的方式，但又需要考虑展示，在展示中大多都是对这个客户的对本次用餐的整体的评价进行展示，而不是去选某一个菜品。所以如果要显示全客户的评价，那么还是第一个设计的方式更好。
而这两种方式会决定两个事情，方式1 对于数据的更新不友好，但对于信息的整体展示友好， 方式2 对于数据的更新友好，对于信息的整体展示略差与第一个设计。 最终根据需求，还是第一个方式被采纳。并且读取信息都是从库优先的策略，并且不需要 write_concern的介入。
所以MONGODB的collection的设计，必须要理解需求，分析需求，最终设计出符合你需求的collection。
这里有10个MONGODB 的schema 的设计小技巧
1 速度优先，使用嵌入数据模式，完整性优先使用引用数据模式
2 读取和写入比例要弄清，读取占比大使用嵌套优先，更新比重大，使用引用优先。
3 每个document 尽量标准化，不要一个 rows 一个样子，KEY VALUE 的次序也尽量一致。
4 查询结果尽量要在单次中获取，尽量不要用$lookup
5 每个document 要有两个field ， createtime , lastupdate, 并且都统一采用ISODATE 作为数据记录的TYPE
6 数组的使用要注意，不要无限制的在数组中加入嵌套，和值。
7 对于未来有值的情况下，尽量先将位置站上，避免后期添加field时在进行空间的分配。
8 不要涉及中针对数组的信息有频繁的增加的操作，一次插入的操作是被建议的
9 如果存入大型的图片或声音文件，尽量不要和查询的内容放入到一个collection ,使用引用的方式，将图片和声音放入到单独的collection中
10 在MONGODB 中使用正确的数据类型
