关系型数据和文档型 数据库有什么区别?

●关系数据库(Relational Database)是建立在关系模型基础上的数据库
借助于几何代数等数学概念和方法来处理数据库中的数据
●所谓关系模型是一对一、一对多或者多对多等关系
常见的关系型数据库有Oracle、SQL Server、DB2、 MySQL 等

●文档型数据库是一种非关系型数据库.
非关系型数据库(Not Only SQL, NoSQL) 正好与关系型数据库相反
它不是建立在“关系模型”. 上的数据库
文档型数据库的典型代表是MongoDB

●关系型数据库属于早期的传统型数据库，它有着标准化的数据模型，以及事务和持久化的支持
例如，关系型数据库都会支持的ACID特性，也就是原子性(Atomicity) 、一致性(Consistency)、隔离性(Isolation) 和持久性(Durability)

• 01原子性(Atomicity) 指一个事务中的所有操作,要么全部完成、要么全部不完成，不会存在中间的状态
  也就是说事务在正常的情况下会执行完成，异常的情况下 比如在执行的过程中如果出现问题，会回滚成最初的状态，而非中间状态
  

关系型数据库三范式

• 要求对属性的原子性，也就是说要求 数据库中的字段需要具备原子性 不能再被拆分
  
• 属性必须依赖唯一主键 例如订单详情表有这些字段:订单ID、产品ID、产品名称、产品单价、折扣 其中，订单ID和产品ID为联合主键 但这个表中的产品名称和产品单价两个字段只依赖产品ID和订单ID就没有任何关系了因此这个表也不符合第二范式.

我们可以把原来的订单表拆分为订单表和产品表，其中订单表包含:订单ID、产品ID、折扣等字段
而产品表包含:产品ID、产品名称、产品单价等字段
这样就消除了产品名称和产品单价多次重复出现的情况了，从而避免了冗余数据的产生.

• 属性字段不能存在传递依赖 想要满足第三范式必须先满足第二范式 第二范式要求所有的非主键字段必须直接 依赖主键，且不存在传递依赖的情况
  

tip : 简单理解 第二范式和第三范式的区别 第二范式 本来只有一张表的 冗余的对象 有没有提取出来设计成为另一张表(原本只有一张表,现在要拆成2张表), 第三范式 在第二范式的基础上 拆分出来的表有没有做到 只关联主键 (已经有两张表 ,有没有做到第二范式基础的上结果,即只存放另一张表的主键ID).

MongoDB 是 文档型数据库的代表

它提供了更高效的读/写性能以及可自动容灾的数据库集群,还有灵活的数据库结构
从而给系统的数据库存储带来了更多可能性
当然MongoDB的诞生并不是为了替代关系型数据库
而是为系统的快速开发提供一种可能性
它和关系型数据库是一种互补的关系
可供开发者在不同的业务场景下选择相对应的数据库类型.

非关系型数据包含了文档型数据库，文档型数据库属于非关系型数据

文档型数据库

• 文档型数据库以MongoDB和Apache CouchDB为代表
• 文档型数据库通常以JSON或者XML为格式进行数据存储
  以MongoDB为例，它是由C++编写的一种面向文档的数据库管理系统

MongoDB

MongoDB是以二进制JSON格式存储数据的，MongoDB 对JSON做了-些优化
它支持了更多的数据类型，这种二进制存储的JSON也可以称之为BSON (Binary JSON)

BSON具备三个特点:轻量、可遍历以及高效
它的缺点是空间利用率不是很理想
●MongoDB使用BSON进行存储的另一个重要原因是BSON具备可遍历性

“_id” 为MongoDB 默认的主键字段，它会为我们生成一起全局唯一的id值,并且这个值在做数据分，片时非常有用.

• 敏捷开发:因为MongoDB拥有比关系型数据库更快的开发速度,因此很多敏捷开发组织 包括纽约时报等都采用了MongoDB数据库
• 使用它可以有效地避免在增加和修改数据库带来的沟通成本，以及维护和创建数据库模型成本
  使用MongoDB只需要在程序层面严格把关就行,程序提交的数据结构可以直接更新到数据库中 并不需要繁杂的设计数据库模型再生成修改语句等过程

●MongoDB在4.0之前是不支持事务的，不支持的原因也很简单
●因为文档型数据库和传统的关系型数据库不-样，不需要满足三范式
●文档型数据库之所以性能比较高的另-一个主要原因就是
使用文档型数据库不用进行多表关联性查询，因为文档型数据库会把相关的信息存放到一张表中
●因此，无需关联多表查询的MongoDB,在这种情况下的查询性能是比较高的
●把所有相关的数据都放入-个表中,这也是MongoDB之前很长一 段时间内不支持事务的原因
它可以保证单表操作的原子性，一条记录要么成功插入，要么插入失败，不会存在插入了一半的数据
●因此,在这种设计思路下，MongoDB官方认为“事务功能”的实现没有那么紧迫
●但在MongoDB 4.0之中正式添加了事务的功能，并且在MongoDB 4.2中实现了分布式事务的功能
至此MongoDB开启了支持事务之旅

● 日志系统:使用MongoDB数据库非常适合存储日志，日志对应到数据库中就是很多个文件
而MongoDB更擅长存储和查询文档，它提供了更简单的存储和更方便的查询功能
●社交系统:使用MongoDB可以很方便的存储用户的位置信息
可以方便的实现查询附近的人以及附近的地点等功能

优点是效率比较高,但是不支持事物.

全文搜索型数据库

全文搜索型数据库以ElasticSearch和Solr为代表
它们的出现解决了关系型数据库全文搜索功能较弱的问题