数据库转成ON格式和json，数据存储方式变得更灵活方便了不少

（根据知乎专栏文章“从关系型数据库到文档型数据库：一种数据思维的转变”中的观点）在过去，我们提到数据库，脑海里浮现出的多半是一张张规整的表格，就像Excel工作表一样，有严格的行和列，这种被称为关系型数据库的方式统治了数据存储领域几十年，它的好处是结构清晰，保证了数据的一致性和完整性，但有时候，这种严格的结构也带来了麻烦，你想为一个用户增加一个“兴趣爱好”的字段，如果这个用户的爱好很多，你可能需要创建一张新的“用户爱好表”，然后用复杂的关联查询才能把数据拼凑起来，或者，如果每个用户的附加信息都不太一样，有的需要记录生日，有的需要记录职业，表格里就会出现大量的空白格子，既浪费空间，处理起来也别扭。

（参考MongoDB官方博客中“为何使用文档数据库”的论述）而如今，随着像MongoDB这样的文档数据库兴起，一种更灵活的数据存储方式变得流行起来，那就是把数据存成类似JSON的格式，或者其二进制变体BSON（可以简单理解为JSON的紧凑版），JSON格式对我们来说非常亲切，因为它和编程语言中的对象（Object）或者字典（Dictionary）结构几乎一模一样，都是“键值对”的集合，要描述一个人，在JSON里可以这样写： { "name": "张三", "age": 30, "hobbies": ["读书", "游泳", "摄影"], "address": { "city": "北京", "street": "朝阳区某街道" } } 你看，这种格式非常直观，所有关于张三的信息都包裹在一个“文档”里，他的爱好是一个数组，想加几个就加几个，不需要为“爱好三”、“爱好四”去单独设计字段，他的地址是一个嵌套的对象，信息也很完整，这种形式就像把一个个完整的“档案袋”塞进数据库，每个档案袋自成一体，结构可以各不相同。

（结合CSDN技术社区多位开发者的实践经验分享）这种转变带来的灵活性是实实在在的，对于软件开发来说，它极大地简化了数据处理流程，在传统的开发中，程序员需要写很多代码，把从数据库表格里查出来的零散数据，“组装”成程序里需要的对象，这个过程叫“对象-关系映射”（ORM），有时候会非常繁琐，而现在，数据库里存的就是类似对象的格式，程序可以直接读取使用，或者稍作转换即可，省去了大量中间步骤，开发速度自然就快了。

它非常适应需求频繁变化的应用场景,比如一个正在快速迭代的互联网产品，今天可能想增加用户等级体系，明天可能想增加社交关注功能，如果用的是传统数据库，每次加新功能都可能需要去修改数据库的表结构，这是个危险操作，弄不好会影响线上服务，但用文档数据库，你只需要在新的用户“文档”里直接加上“level”字段或者“following”数组就行了，老的用户文档没有这些字段也没关系，程序可以处理这种情况，这种模式叫“无模式”或“动态模式”，它给了开发团队很大的自由度，不用在项目初期就把所有数据字段都定死。

对于存储一些非结构化的数据,文档格式的优势就更明显了，比如一篇文章的评论，有的评论可能只有文字，有的可能带了图片，有的可能还有用户@了其他人，这种不规则的数据，用表格来存会很吃力，但用JSON文档存就非常自然，可以轻松容纳各种复杂和多变的情况。

任何技术都不是万能的。（同样基于知乎和CSDN上关于数据库选型的讨论）这种灵活的文档存储方式也有它的短板，当数据之间有非常复杂的、需要跨多个文档进行关联和查询的关系时，传统关系型数据库通过JOIN操作可能更高效、更清晰，文档数据库虽然也支持类似功能，但在处理非常复杂的多表关联时，可能不如关系数据库得心应手，事务一致性方面，传统关系型数据库经过几十年发展，有非常成熟和强大的事务保证机制，这在金融、交易等对数据一致性要求极高的场景下几乎是必须的，虽然现在很多文档数据库也在不断加强事务支持，但在这方面的成熟度上仍有差距。

数据库从规整的表格转向灵活的JSON-like文档，并不是说后者要完全取代前者，它更像是为我们提供了一种新的、更贴合现代应用开发节奏的工具选择，当你的数据模型相对稳定，业务逻辑复杂，需要强一致性保证时，传统关系型数据库依然是可靠的选择，而当你的应用需要快速迭代，数据结构多变，或者数据本身就更像是一个个独立的复杂对象时，采用文档型数据库无疑会让数据存储和处理变得灵活方便不少，让开发者能更专注于业务逻辑的实现，而不是在数据转换和结构迁移上耗费过多精力，这种选择权，本身就是技术进步带给我们的便利。