关系型数据库和非关系型数据库的区别

前言

使用数据库来保存用户或者公司业务的具体数据，是项目运作的常规操作。开发人员也势必需要选择符合实际业务需求和特点的数据库来作为数据存储工具。那么作为开发人员，你是否了解关系型和非关系型数据库之间的差异呢？针对公司的实际业务，又应该选择哪种数据库来应用到项目中呢？
希望这篇文章能够给到阅读者一定的参考

先说结论，两种数据库本质的区别在于存储数据的形式不同

关系型数据库

关系型数据库最大的特征就是表，我们将对象的属性映射为表的一个个列名，将数据按照对应关系逐行填充。（如下图）我们对数据进行CRUD的时候，都是基于表中的一行行数据进行操作的。

image.png

也就是说，我们想要插入一条歌手数据（结合上图）的时候，除了添加歌手名称之外，还得补充上歌手性别、出生日期等其他数据才行，除非是表设计的时候对于某些字段做了允许为空的设置，否则我们必须保证表中存储数据的完整性。
这样麻烦吗？
确实麻烦，因为我们持久化数据的时候就需要保证数据的完整性
这样做有什么好处吗？
确实有，正因为数据的完整性，才保证了数据的安全性和稳定性。我们可以通过SQL语句，关联查询出我们需要的数据，而不会出现表中存在例如歌手名称为空的数据了。
当然了，关系型数据库的功能远不止上面这些，还包含主键、外键约束，事务管理等极为庞杂的校验和功能，可以说，关系型数据库虽然使用麻烦，但能够很大程度上保障我们数据的安全。

非关系型数据库（NoSql --> no only sql）

和前者对比，非关系数据库的存储方式则是更为熟悉和常见的结构：键值对，我们通过key：value的形式来保存对应的数据。
用之前的歌手表作为例子，我们可以用 id : 15 ,singer_name：刘德华, singer_sex：0 ...来表示一条数据，这里面并没有用到表结构，但是二者实际的存储数据并没有任何变化。这样的话，就带来一种好处，我可以根据业务需要很方便地修改存储的键，比如要新增多一个歌手热度字段，只需要多加一个key值即可。不再需要像传统的关系型数据库一样，调整表结构了。
非关系型数据库的好处显而易见，拓展性高，约束性小，操作速度快
但同时，劣势也在此。对于需要高度安全的数据，非关系型数据库就无法保证了。

这里再介绍一下关系型数据库和非关系型数据库的常见代表例子：

关系型数据库：

MySQL
早期的关系型数据库代表，由于其社区版免费、开源的特点，受到中小型企业和个人的喜爱和推崇。后面MySQL被sun公司收购，sun公司又被Oracle收购，最新的版本应该不是免费的了。
Oracle
大多数大型商业公司的选择，Oracle支持高并发,大访问量，支持事务，数据库性能好，稳定性高，但是是收费的。

非关系型数据库

MongoDB
MongoDB是一个基于分布式文件存储的数据库。由C++语言编写。旨在为WEB应用提供可扩展的高性能数据存储解决方案。
Redis
比较典型的Nosql数据库，其优秀的缓存机制更是开发人员常常使用到的功能之一。
最后，再总结一次
1、无论是关系型和非关系数据库，二者最终存储到数据库中的表现形式并没有差异，只是存储的方式不同而已。
2、在安全性上，关系型数据库由于各种约束的限制，数据会更有保障。
3、 在学习成本上，如果不深究底层实现原理的话，其实非关系型数据库会更好上手，不需要额外学习sql语法。
针对上面的讲解，我们可以容易的推算出，对于业务变动较大和频繁，经常需要修改字段，对安全性要求不高的数据而言，使用非关系型数据库是一个很好的选择。反之，如果业务对于数据有着比较高的安全性要求，那么现阶段使用关系型数据库会是更好的选择。