回顾一下：
SQL 数据库:
·在表中存储相关联的数据
·在使用之前需要定义表的一个模式
·鼓励标准化减少数据冗余
·支持从多个表中检索相关数据表连接在一个单一的命令
·实现数据完整性规则
·提供事务使两个或两个以上的成功或失败的数据更改作为一个原子单元
·可以扩展(有一些努力)
·使用一个强声明性语言查询
·提供足够的支持,专业技能和工具。
NoSQL 数据库
·将相关联的数据存储在类似 JSON 格式，名称-值
·可以保存没有指定格式的数据
·通常必须规范化，所以一个项目的信息包含在一个文档里
·应该不需要连接（假设使用规范化的文档）
·允许任何数据被保存在任何时候任何地方，不需要验证
·保证更新一个文档 – 但不是多个文档
·提供出色的性能和可伸缩性
·使用 JSON 数据对象查询
·是一个新的、令人兴奋的技术。
SQL 数据库是一个理想的项目，确定好了需求和健壮的数据的完整性是至关重要的。NoSQL 数据库是无关理想，不确定的或者不断变化的数据需求 ，在速度和可伸缩性上更重要。 简单的术语：
·SQL 是数字。它最适合明确的定义，精确规范的独立项目。典型的使用案例是在线商城和银行系统。
·NoSQL 是模拟。它最适合无固定要求的组织数据。典型的使用案例是社交网络，客户管理和网络分析系统。
一些项目要精准的符合。如果你有较浅的话，任何一种选择都是可行的，或者自然的非规范数据。但是请注意这些简化示例场景与全面的概括！你比我更了解你的项目，我不建议切换从SQL到NoSQL或反之亦然，除非它提供了可观的效益。这是你的选择。在项目的开始要考虑利弊,你不能出错。
场景一:一个联系人列表
让我们重新发明轮子，实现一个基于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 地址和住址的标准化数据库。不幸的是……
