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

事实上很多人把关系型数据库当非关系型数据库来用

用 SQL vs 不用 SQL

一张表，一个是字典吧

个人看法：（最初的）非关系型数据库就是没有达到关系型数据库要求(例如 ACID)的数据库

现在很多 NoSQL 也慢慢支持了一些关系型数据库的要求，所以他们两者在进行一些简单应用的时候并不是“天壤之别”。在使用中都能对指定字段存储指定的数据，关系型数据库中那些复杂的东西一概不碰（这就是 @wy315700 说的很多人把关系型当非关系型来用）

sql 和 nosql 了，自己做之类的项目时，就会有体会啦。

关系型存的是 table 非关系型存的是 object

找本 nosql 的书看下，比如 redis in action ，其中有个对别的列表，大同小异，看书自己总结岂不是更好咩=。=

sql 一般是先创建表设计好数据的结构和相互之间的关系，存储固定格式的数据，使用支持条件查询的 SQL 语句。 nosql 就反之数据更松散灵活存储的数据没有固定的格式，直接用代码更容易看出其区别。

典型的例如操作 sqlite 的代码（ aardio 代码 ）
import sqlite;
var db = sqlite("/sqlite.db") //创建数据库
db.exec("CREATE TABLE IF NOT EXISTS [film](title);")//创建表
db.exec("REPLACE INTO film VALUES ('title')") //增加数据
for rowid,title in db.each("SELECT rowid,* FROM film WHERE title LIKE '%t%'") {
console.log( rowid,title, length, year, starring ) //查询数据
}

操作 unsqlite 的代码则不需要使用 SQL 语句，用 JSON 就可以，例如（ aardio 代码 ）：
import unqlite;
var udb = unqlite("/unqlite.db");// 创建数据库
udb.storeObject("jsonObject",{ name = "测试"; 随便搞="随便随便"} ) // 存储 json 数据
udb.fetchObject("jsonObject",function( value ){
console.dumpJson( value ) // 查询 json 数据
} )

关系数据库操作的基本单位是集合.
这么说其实也特别市书本化...

直观的说：

关系数据库你可以理解为是一个包含了很多 sheet 的 excel 文件，里面有很多表，每个表有列有行。

非关系型数据库你就把它想成一个文件夹放很多 ini 或者 conf 文件，每个文件是个对象，里面有它的属性和内容。

（这只是一种类比，实际上并不是这样，但是你这样想就比较好理解）

非专业解释——
「数据库」不解释了。
「关系型」：盒子 A 是装胳膊的，盒子 L 是装腿的，盒子 H 是装头的，还有装梯子的、装板凳的、装肥皂的……要想拼出一个人，得先知道哪些盒子是拼人需要的，然后还要知道这些盒子分别对应什么部位，然后从各个盒子里找出符合条件的零件出来。
「非关系型」：仓库 D 是装狗的，仓库 C 是装樱桃的，仓库 P 是装人的……唉！你怎么长这么高啊，那你站天窗下边吧，至少有地方放你的脑袋了。

PS: 是不是太抽象了……

楼上说的挺形象，哈哈。不过楼主用过关系数据库吗， SQL Server ， MySQL ， Oracle 啥都成，如果没用过，就不好解释了。如果接触过。看一下 Martin Fowler 的 NoSQL 精粹，就 100 多页。基本上就啥都明白了。

简单来说区别在于数据库软件是否负责维护数据间的关系。

关系型数据库是依照实体-关系模型建立起来的，它包括两个部分：一是数据库部分，负责数据的保存和索引，让你完成增删改查操作；另一个是关系部分，利用数据表把数据按行的形式组织起来，检查每个字段的数据类型、长度甚至取值范围，利用外键约束数据表之间的关系，利用事务机制确保数据库操作的 ACID 特性。

非关系型数据库全部或者部分放弃了实体-关系模型，它们只负责保存数据，并不组织数据表，也不约束表间关系，关系的部分交由开发人员自己来完成。比如 MongoDB 用 JSON 序列化的方式保存数据，虽然也有表的概念，但是结构可以随时扩展调整，而无需更新既有数据。比如 LevelDB 是一个 Key-Value 数据库，重视写入性能而非读取性能。 Redis 提供了 Key-Value 、 List 、 Set 、 Sorted Set 等多种数据结构模型。 Cassandra 则使用面向列的数据模型。

关系型数据库设计之初是为了给国防、金融、政府及企业管理使用，对数据一致性要求极高，再加上当年存储成本高昂，业界努力的方向也是确保事务安全和减少数据冗余。实体-关系模型提供了简单易学、健壮可靠，相对通用的软件数据建模方法，自然成为各种数据库软件的基础模型。非关系型数据库早就存在，但是因为缺乏必要的数据一致性保障而未能流行。直到 SNS 时代，社交网络应用对数据的一致性要求相对较低，对数据处理的实时性要求和大并发处理能力方面的要求非常高。通过放弃一致性检查和事务机制，非关系型数据库一般比关系型数据库拥有更好的性能，而且也不局限于实体-关系模型，能有更灵活的数据模型和操作方式供开发人员使用。

未来的趋势是两者结合， PostgreSQL 作为老牌的 RDBMS 开始提供 JSON 等更灵活的数据字段， Redis 等典型的 NoSQL 系统也开始提供 atom 操作接口。

不存在哪种数据库更好，请按自己的实际业务场景结合起来使用。

我的理解是，关系型是倾向于范式化，非关系型是倾向于反范式化的。

这种应该上升到高大上的理论的东西去找写 paper 或者 CS 、数据库的书看下比较透彻，然后再回过头来看实际问题，比较好——个人体会

@blank4me 所以使用关系型数据库做反范式化的能力很重要

为了 mongo 的自增，还特意再开个集合来记录... 我是不是用的姿势不对？ ORZ...

其实我 oracle 和 mongodb 都用过，但是紧紧用过...

@lyndonneu18 把数据库想象成一个箱子。你往 Oracle 型箱子放东西前必须用盒子装起来（盒子即是表），而且规定了一个盒子里只能放规格一致的东西（表中的记录都拥有相同的字段）。你往 MongoDB 型箱子放东西时就没那么多限制了，只管放就行了，怕太乱就也用盒子装起来（盒子即是集合），但没有规格一致的限制（集合中的记录可以有不同的字段）。

@SilentDepth 太感谢了！！听明白了~~~