为什么我们选择了MongoDB？( 三 ) _MongoDB

①灵活的 Schema
在关系型数据库中，必须按照确定的表结构去插入数据。但是，由于 MongoDB 是文档型数据库，在插入数据的时候默认并不对此做要求。
其表现在于：

同一个集合中不同文档不一定需要有相同的字段，并且字段类型也可以不同。
在集合中改变文档的结构，例如增加一个字段，删除一个字段，或者改变一个字段的类型，只需要对该文档更新即可。

②举例 1：N 模型设计
在电商业务中，一个用户可能有多个收件人以及收件地址。在关系型数据库中，我们需要建立联系人表，地址表，并且将其关联。但是在 MongoDB 中，我们只需要一个集合就能将此搞定!
数据关系如下：

// patron document {_id: "joe",name: "Joe Bookreader" }// address documents {patron_id: "joe", // reference to patron documentstreet: "123 Fake Street",city: "Faketon",state: "MA",zip: "12345" }{patron_id: "joe",street: "1 Some Other Street",city: "Boston",state: "MA",zip: "12345" }

在 MongoDB 中我们可以这样进行设计：

{"_id": "joe","name": "Joe Bookreader","addresses": [{"street": "123 Fake Street","city": "Faketon","state": "MA","zip": "12345"},{"street": "1 Some Other Street","city": "Boston","state": "MA","zip": "12345"}]}

没错，以上就是集合中的一个 document(文档)，是不是感觉很灵活很方便!
你可以在 SKU 集合中添加分类信息，或者商品标签，还可以在库存集合中冗余 SKU 的基本信息，还可以在订单集合中冗余部分下单者信息···没错，就是这么灵活!
这也是我们选择 MongoDB 的一个重要原因之一，让开发者的心智负担少了很多，不需要成为 SQL 高手，你也能在 MongoDB 中写出性能优异的查询语句。
当然，“冗余一时爽，重构火葬场”的段子也不是没听过，因为过多的冗余最终会造成数据的过于臃肿，性能降低等各种问题，这个要控制住开发者的冗余冲动，也依赖于团队技术 Leader 对此的把关。
总结
互联网业务不是一成不变的，产品和用户的需求还有市场都一直在变!我们没有技术实力打造一个能够适应灵活多变的业务的中台，但是目前我们可以选择一个可靠，强大并且灵活的数据库 MongoDB!
作者：唐银鹏
简介：开源爱好者、Gopher 。从事电商、IM 系统深度研发，MongoDB 爱好者，公众号《从菜鸟到大佬》作者。
编辑：陶家龙
出处：转载自微信公众号Mongoing 中文社区(ID：mongoing-mongoing)，本文是唐银鹏在“青芒话生长”MongoDB征文比赛的获奖文章。

【为什么我们选择了MongoDB？】