摘要：中集合概念就是关系型数据库中的表，本文讨论的内容主要集中在数据库库设计集合时关键原则和常见的设计误区。第一条准则抛弃关系型数据库设计的范式约束，摒弃关联查询。的设计原则建议多种对象以关联嵌套的方式组织在一个文档中，方便应用程序一次读取。
MongoDb中集合概念就是关系型数据库中的表，本文讨论的内容主要集中在MongoDb数据库库设计集合时关键原则和常见的设计误区。本文约定读者对MongoDb的基本概念有一定的了解。
第一条准则
抛弃关系型数据库设计的范式约束，摒弃关联查询。先考虑内嵌形式，再考虑引用，视使用场景而定。内嵌就是充分利用MongoDb的文档特定，通过嵌套文档的形式，将一组数据统一保存在一个文档下。即一条记录中，这样在列表类的需求中，就不需要多表查询，以及外键关联。
MongoDb的设计原则建议多种对象以关联嵌套的方式组织在一个文档中，方便应用程序一次读取。
注意这里说的是建议，不是【必须】，因为有特定场景下，完全嵌套是不能满足存储需求的。
第二条准则
文档中不是每个字段都必须有值，也就是每行的字段可以不一致。控制字段尽量不插入null值和空值，这样可以节约内存存储，MongoDb中的稀疏索引类型专门为【不是每个文档都有的字段】而设计。
这种特性适合Iot数据采集类似的使用场景，每个文档的字段数目不等，按需插入。
注意这种情况下，切忌文档过宽。那如何避免这种情况，我的方法是预估最大字段数，以20个字段为节点，多于20则采用嵌套document的设计方式组织document。
第三条准则
时间可以直接定义为格式化的时间，便于识别和查询。不必特意存储时间戳，这样方便可视化的工具查询核对。
"create_time" : ISODate("2017-05-10T15:39:58.000+08:00"),
当然如果系统涉及到不同时区的国际化，最好把原始时间戳记录下来，视情况是否记录源时区。
第四条准则
字段长度尽可能的短，不宜过长。也是考虑到内存优化。MongoDb存储原则中会把key也存储到内存中，所以字段因尽可能的短，这样势必会减低字段的可读性，是的，这里需要牺牲字段的可读性。
新概念
分桶设计原则
我们知道许多传感器数据都是时间序列数据。例如：风传感器，潮汐监测以及位置追踪等采集数据的无非这种类型： Timestamp，采集器名称/ID，采集值。对于时序类型的数据，我们可以采用一种叫做时间分桶的优化策略。 所谓分桶优化，就是与其对每一条数据创建一个文档，我们可以把某一个时间段内的测量数据聚合到一起放到一个文档内，利用MongoDB提供的内嵌式数组或子文档特性
参考资料
http://www.mongoing.com/mongo...
http://www.tuicool.com/articl...
https://segmentfault.com/q/10...
文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。
转载请注明本文地址：https://www.ucloud.cn/yun/19038.html
摘要：然后又介绍了基于的公号账本应用的数据库设计。欢迎关注公号四月试用。 前两篇 微信公号DIY 系列: 微信公号DIY：一小时搭建微信聊天机器人 微信公号DIY：训练聊天机器人&公号变身图片上传工具 介绍了如何使用搭建&训练聊天机器人以及让公号支持图片上传到七牛，把公号变成一个七牛图片上传客户端。这一篇将继续开发公号，让公号变成一个更加实用的工具账本（理财从记账开始）。 代码： 项目代...
摘要：然后又介绍了基于的公号账本应用的数据库设计。欢迎关注公号四月试用。 前两篇 微信公号DIY 系列: 微信公号DIY：一小时搭建微信聊天机器人 微信公号DIY：训练聊天机器人&公号变身图片上传工具 介绍了如何使用搭建&训练聊天机器人以及让公号支持图片上传到七牛，把公号变成一个七牛图片上传客户端。这一篇将继续开发公号，让公号变成一个更加实用的工具账本（理财从记账开始）。 代码： 项目代...
摘要：然后又介绍了基于的公号账本应用的数据库设计。欢迎关注公号四月试用。 前两篇 微信公号DIY 系列: 微信公号DIY：一小时搭建微信聊天机器人 微信公号DIY：训练聊天机器人&公号变身图片上传工具 介绍了如何使用搭建&训练聊天机器人以及让公号支持图片上传到七牛，把公号变成一个七牛图片上传客户端。这一篇将继续开发公号，让公号变成一个更加实用的工具账本（理财从记账开始）。 代码： 项目代...
摘要：因为他们可能会有许多顾客对相同的商品目录进行多次请求。然而，对于我们的参考架构，我们想完全在中实现一个多方面搜索。 本文源地址：http://www.mongoing.com/blog/retail-reference-architecture-part-1 如今，产品目录数据管理对零售商而言是一个非常复杂的问题。经过多年对多个庞大、由供应商提供的系统的依赖之后，零售商目前正在重新考...
摘要：因为他们可能会有许多顾客对相同的商品目录进行多次请求。然而，对于我们的参考架构，我们想完全在中实现一个多方面搜索。 本文源地址：http://www.mongoing.com/blog/retail-reference-architecture-part-1 如今，产品目录数据管理对零售商而言是一个非常复杂的问题。经过多年对多个庞大、由供应商提供的系统的依赖之后，零售商目前正在重新考...
阅读 2802·2021-10-12 10:20
阅读 2570·2021-09-27 13:56
阅读 632·2021-09-27 13:36
阅读 1248·2021-09-26 09:46
阅读 2294·2019-08-30 14:02
阅读 2572·2019-08-28 18:14
阅读 1141·2019-08-26 10:32
阅读 1558·2019-08-23 18:25
