这篇文章给大家介绍MongoDB几个问题梳理和复盘过程是怎样的，内容非常详细，感兴趣的小伙伴们可以参考借鉴，希望对大家能有所帮助。工作中主要负责的系统主要以MongoDB数据库为主，开发过程中积累了一些经验和实际使用case，前一段时间把相关的场景整理了一下，组织了几篇文章。
当我尝试想把这些文发布到MongoDB中文社区时，与负责人沟通后，他们提出了一些文章中有待商榷和不严谨的地方，我在这里做一个梳理和复盘修正。《MongoDB开发系列-从数据集合的设计开始 》中写到时间可以直接定义为格式化的时间，便于识别和查询。不必特意存储时间戳，这样方便可视化的工具查询核对。这里的格式化的时间有歧义，会被认为是时间字符串，比如（2019-07-03 19:10:11），我的本意是想表达使用ISODate类型的时间格式存储。时间戳和时间格式两个数据类型的存储是一个选择问题，有的人习惯使用时间戳存储，有的人习惯用时间类型存储。建议存时间戳的认为，时间转换成字符串很方便，字符串转换成时间很不方便。还有效率的问题。字段长度尽可能的短，不宜过长。也是考虑 香港云主机到内存优化。原厂专家的建议是实际并不存在长短的问题，因为有压缩，字段名这种重复的字段压缩后可以忽略最开始我在考虑MongoDb是基于内存和key value形式的数据库，关于【命名规范，短字符的建议】这一条，我在官方和社区都没有找到正面的回应。官方的文档大多是以小写命名做字段定义的，所以对于这个观点 我也是在逐步否定，或者说这种做法对内存的优化并不明显，反而牺牲了字段语意化，增加了开发字段映射和沟通成本。官方文档示例
正常的做法是：按照驼峰或者全部小写的语义化命名即可注意这种情况下，切忌文档过宽。那如何避免这种情况，我的方法是预估最大字段数，以20个字段为节点，多于20则采用嵌套document的设计方式组织document。这是工作中的设计经验，有不严谨的地方，容易误导读者。不应该有20的这个量化数据，我的本意是，如果一级属性太多，可以整理为二级嵌套字段，仅此而已。关于MongoDB几个问题梳理和复盘过程是怎样的就分享到这里了，希望以上内容可以对大家有一定的帮助，可以学到更多知识。如果觉得文章不错，可以把它分享出去让更多的人看到。
这篇“如何在html中调用下级目录的图片”文章的知识点大部分人都不太理解，所以小编给大家总结了以下内容，内容详细，步骤清晰，具有一定的借鉴价值，希望大家阅读完这篇文章能有所收获，下面我们一起来看看这篇“如何在html中调用下级目录的图片”文章吧。引用下级目录的…
免责声明：本站发布的图片视频文字，以转载和分享为主，文章观点不代表本站立场，本站不承担相关法律责任；如果涉及侵权请联系邮箱：360163164@qq.com举报，并提供相关证据，经查实将立刻删除涉嫌侵权内容。
微信扫一扫 
