在这个示例中，我们没有存储这个人的性别和职衔，并且可以添加一些别的联系人没用的信息。在NoSQL中这样的存储是合法的，并且我们可以按照各人的意愿来添加和删除一个字段。
　　因为一个联系人存储在一个文档中，因此我们可以使用一个查询语句取出一个人的所有信息。对于全文搜索，在MongoDB中我们可以在 contact 的字段中定义一个索引：
　　db.contact.createIndex({ "$**": "text" });
　　然后我们可以使用如下的语句进行全文搜索:
　　db.contact.find({
　　$text: { $search: "something" }
　　});
　　场景二：社交网络
　　一个典型的社交网络使用的联系人的信息是相似，但是也会增加一些新的功能例如：社交网络，状态更新，私信和点赞。这些功能会根据用户的需求进行添加或者删除，预测用户的需求对开发人员来说是非常困难的。
　　另外：
　　大多数的更新都有一个原始的出发点：用户。但是，对于开发人员来说一次性的把所有的回馈都进行更新是不可能的。
　　不管用户怎么想，一个失败的版本并可能造成太大的经济损失。一个应用的接口设计和功能表现是比数据的完整性的优先级要高。
　　因此，NoSQL是一个不错的选择。数据库允许我们存储不同类型的数据以便于我们快速的开发出新的功能。例如，因为所有的数据状态的更新都可以在 status 的集合中的一个文档中进行：
{
user_id: ObjectID("65f82bda42e7b8c76f5c1969")，
update: [
{
date: ISODate("2015-09-18T10:02:47.620Z")，
text: "feeling more positive today"
}，
{
date: ISODate("2015-09-17T13:14:20.789Z")，
text: "spending far too much time here"
}
{
date: ISODate("2015-09-17T12:33:02.132Z")，
text: "considering my life choices"
}
]
}
　　尽管对于这个文档来说数据会变得多一些，但是我们可以仅仅取出文档的一个子集，例如：新的状态等。对于每一个用户来说历史记录也会很容易搜索的到。
　　场景三：仓库管理系统
　　现在，我们来分析一下一个仓库的管理系统。我们需要记录如下的信息：
　　货物入库的信息和存放的位置信息
　　货物在仓库中的移动，例如：为相同的货物分配相邻的位置存放
　　货物的摆放顺序以及配送货物之后的一系列问题。
　　数据需求：
　　保存货物的基本信息例如：尺寸、大小、颜色等，这些不相关的数据我们要能够用到任何的货物上。我们不可能去考虑一些货物个性化的信息例如：笔记本处理器的速度或者是一部手机电池的寿命。
　　我们要尽可能的避免错误的发生。我们不能让货物凭空消失或者将货物存放到已经存放货物的位置上去。
　　以更加简单的方式操作。我们记录将一件货物从一个位置移动到另一个位置或者从A移动到B的操作是相同的。
　　因此，我们需要考虑对数据的完整性和对于事务的支持。目前来说也是SQL能够很好地满足我们的需求。
　　总结
　　我希望上述的案例能够对你有一定的帮助，但是每一个实际的项目都是不同的，对一无二的你需要自己去做决定选择一种适合的。 （尽管，对于我们开发人员来说我们不太愿意去改变我们现有的选择，无论新的技术有多好！O(∩_∩)O）
　　建议：去尝试了解更多新的技术。这样我们可以非常有理由的选择一种数据库进行开发。祝你好运！