SQL的表 vs NoSQL的文档

SQL数据库提供了一族相关的数据表。举例来说，如果你在运营一个线上的书店，书的信息可以被加入到一个叫book的表。

每一行都是一条不同的书德尔记录。这种设计是比较苛刻的，你没法使用同样的表去存储不同的信息或者在是数字类型的字段插入字符串。

NoSQL数据库存储类JSON的键值对文档：

{ISBN: 9780992461225, title: "JavaScript: Novice to Ninja", author: "Darren Jones", format: "ebook", price: 29.00
}

相似的文档可以被存储进一个集合，这跟SQL表十分类似。但是，在文档里面你可以存储任何形式的数据，NoSQL数据库并不会抱怨：

{ ISBN: 9780992461225, title: "JavaScript: Novice to Ninja", author: "Darren Jones", year: 2014, format: "ebook", price: 29.00, description: "Learn JavaScript from scratch!", rating: "5/5", review: [ { name: "A Reader", text: "The best JavaScript book I've ever read." }, { name: "JS Expert", text: "Recommended to novice and expert developers alike." } ]
}

SQL表创建的是严格的数据模板，所以你很难犯错。而NoSQL更加灵活，但是能够在任何地方存储数据可能会导致持续的问题。

SQL架构 vs NoSQL去架构

在一个SQL数据库中，在你确定表和字段类型这些架构之前是无法添加数据的。SQL架构还可能包括其他的信息：

• primary keys: 主键，就像ISBN一样标示了唯一的一条记录
• indexs: 索引，经常被查询的字段会被加上索引来提高检索速度
• relationships: 关系，数据字段之间的逻辑联系
• 诸如存储过程和触发器这样的机制

你的数据架构一定要在实现任何操作数据的应用逻辑之前被设计和实现出来。尽管之后再修改是可行的，但是大量的变更会非常复杂。

在NoSQL数据库中，数据可以被非常灵活的添加。并不需要事先进行字段设计和表的设计。比如说，在MongoDB中，下面的命令会在book表中创建一条新的记录，如果book表不存在，那它也会被同时创建：

db.book.insert(ISBN: 9780994182654, title: "Jump Start Git", author: "Shaumik Daityari", format: "ebook", price: 29.00
);

(MongoDB会自动在表中添加一条唯一的_id字段，随后你也可以对索引进行定义。)

一个NoSQL数据库可能更适合初始数据形式很难确定的项目中。但这并不意味着，你可以因此而偷懒：在项目开始的时候忽视设计正确的数据表，可能会在之后引入问题。

SQL 中心化 vs NoSQL去中心化

假定我们需要往book数据库中添加出版社信息。在SQL数据库中，一个出版社会包含多个标题，我们创建了一张新的publisher表：

我们可以在book表里面添加一个publisher_id字段，来作为publisher.id的外键。

这使得数据冗余被最小化，我们不必为每本书重复出版社的信息--只需要创建外键就行了。这种技术被称为中心化，而且也确实很有益处。我们可以在不用修改book的数据的前提下更新出版社信息。

在NoSQL中我们也可以使用中心化的技术。看一下在book集合中得一条文档：

{ ISBN: 9780992461225, title: "JavaScript: Novice to Ninja", author: "Darren Jones", format: "ebook", price: 29.00, publisher_id: "SP001"
}

-- 引用了一条在publisher集合中得一条文档：

{ id: "SP001" name: "SitePoint", country: "Australia", email: "feedback@sitepoint.com"
}

然而这有的时候却并不实际。更希望的是能够把数据去中心化，对每一个book重复冗余的publisher.

{ ISBN: 9780992461225, title: "JavaScript: Novice to Ninja", author: "Darren Jones", format: "ebook", price: 29.00, publisher: { name: "SitePoint", country: "Australia", email: "feedback@sitepoint.com" }
}

这会使我们查询的更快，但是再多条记录中更新publisher信息，会非常的慢。

SELECT book.title, book.author, publisher.nameFROM bookLEFT JOIN book.publisher_id ON publisher.id;

场景一:一个联系人列表

让我们重新发明轮子，实现一个基于sql的通讯录系统。我们最初接触表的时候，天真的定义以下字段：

• id (主键ID)
• title (标题)
• firstname （姓）
• lastname （名）
• gender （性别）
• telephone （电话）
• email （邮箱）
• address1 （地址1）
• address2 （地址2）
• address3 （地址3）
• city （城市）
• region （区/县）
• zipcode （邮政编码）
• country (国家)

问题一: 很少人只有一个电话号码。我们可能需要至少三个号码：一个座机，一个移动电话，一个工作电话。但是有多少个号码无关紧要——有些人、有些地方需要更多。让我们创建一个单独的 telephone 表，这样的话他们想要多少联系人都可以。这也让我们的数据标准化了——我们不需要没有号码的联系人显示为NULL。

• contact_id
• name (文本，例如座机号，工作手机等)
• number

问题二：Email地址有同样的问题，因此我们也创建一个类似的 email 表：

• contact_id
• name (text such as home email, work email, etc.)
• address

问题三：我们可能不想输入一个（地理位置的）地址，或者我们想输入多个地址，工作地，家里，度假住所等。因此我们需要一个新的 address 表：

• contact_id
• name (text such as home, office, etc.)
• address1
• address2
• address3
• city
• region
• zipcode
• country

我们原来的 contact 表简化成：

• id
• title
• firstname
• lastname
• gender

太棒了——我们有了一个能存放任意联系人的任意多个电话号码，Email 地址和住址的标准化数据库。不幸的是……

Schema是固定不变的

我们没有考虑到联系人的中间名字、出生日期、公司或职位。我们添加多少字段都没关系，我们很快会受到更新的需求要添加备注、纪念日、关系状态、社交媒体账号、内腿测量值、最喜欢的奶酪类型等字段。预测所有选项是不可能的，因此我们可能需要一个 otherdata 表，用来处理名字-值对。

数据是碎片化的

对开发者或者系统管理员来说，检查数据库并不容易。程序逻辑会变得更慢、更复杂，因为利用单个 SELECT 和多个 JOIN 语句查询联系人数据不太实际。(你可以这么做，但是结果可能需要包含 telephone，email，和 address字段的每一种组合：如果有个联系人有三个电话号码，五个Email地址和两个住址，那么SQL查询将会产生30条结果。) 最后，全文搜索很困难。如果有人输入字符串”SitePoint”，我们必须检查所有的表，看看它是否为联系人名字、电话、Email或者住址的一部分，并且需要做相应的排序。如果你用过WordPress的搜索功能，你就会明白这有多虐心。

选择NoSQL

我们的联系人数据关注的是人。他们难以预测，在不同的时间有不同的需求。使用NoSQL数据库，联系人列表将会从中受益。数据库将一个联系人的所有数据存储在一个单独的文档里的contacts 集合里。

在这个例子里，我们没有存储联系人的头衔或者性别，我们还添加了一些数据，而这些数据不需要应用到任何其他联系人。没关系——我们的NoSQL数据库不会介意，我们还可以随意添加或移除字段。

由于联系人数据在单独的文档里，我们可以用一条查询语句获取一部分或全部信息。全文搜索也变得简单；在MongoDB里，我们可以这样定义 contact 中的所有文本字段的索引：

然后执行全文搜索：

场景二：社交网络

社交网络可能使用类似的联系人数据存储，但是它会根据功能集合扩展，比如关系链、状态更新、发送消息和”赞“。这些功能可能会根据用户需求来实现或者移除——无法预测它们会怎样演进。

另外:

• 大部分的数据更新都来自单个源：用户。任何时候我们不太可能同时更新两条或更多记录，因此不要求类似事务控制的功能。
• 尽管有些用户可能认为，状态更新失败不可能引起系统崩溃或经济损失。应用程序的接口和性能比数据完整性优先级更高。

NoSQL看来是个好的方案。它允许我们快速地实现存储不同类型数据的功能。例如，可以用单个文档里的 status 集合替换所有用户的过时的状态更新。

文档可能会变得很长，但我们可以获取数组的子集，比如最近的更新。每个用户的所有的历史状态记录都能被快速搜索到。

现在假设我们想在发布更新的时候引入表情符号选择。这涉及到给 update 数组里的新记录添加图引用。不像 SQL 存储，没必要把之前消息里的表情符号置为 NULL——我们的程序逻辑可以显示默认图片或者没有图片，如果没有设置表情符号的话。