在前一篇文章中,我们讨论了 SQL 与 NoSQL 数据库之间基本的区别。接下来,我们我们将应用我们在特定场景中的知识来确定最佳的选择。 回顾一下: SQL 数据库:
|
NoSQL 数据库
SQL 数据库是一个理想的项目,确定好了需求和健壮的数据的完整性是至关重要的。NoSQL 数据库是无关理想,不确定的或者不断变化的数据需求 ,在速度和可伸缩性上更重要。 简单的术语:
|
一些项目要精准的符合。如果你有较浅的话,任何一种选择都是可行的,或者自然的非规范数据。但是请注意这些简化示例场景与全面的概括!你比我更了解你的项目,我不建议切换从SQL到NoSQL或反之亦然,除非它提供了可观的效益。这是你的选择。在项目的开始要考虑利弊,你不能出错。 场景一:一个联系人列表让我们重新发明轮子,实现一个基于sql的通讯录系统。我们最初接触表的时候,天真的定义以下字段:
|
问题一: 很少人只有一个电话号码。我们可能需要至少三个号码:一个座机,一个移动电话,一个工作电话。但是有多少个号码无关紧要——有些人、有些地方需要更多。让我们创建一个单独的 telephone 表,这样的话他们想要多少联系人都可以。这也让我们的数据标准化了——我们不需要没有号码的联系人显示为NULL。
问题二:Email地址有同样的问题,因此我们也创建一个类似的 email 表:
问题三:我们可能不想输入一个(地理位置的)地址,或者我们想输入多个地址,工作地,家里,度假住所等。因此我们需要一个新的 address 表:
|
我们原来的 contact 表简化成:
太棒了——我们有了一个能存放任意联系人的任意多个电话号码,Email 地址和住址的标准化数据库。不幸的是…… Schema是固定不变的
|
数据是碎片化的
|
选择NoSQL我们的联系人数据关注的是人。他们难以预测,在不同的时间有不同的需求。使用NoSQL数据库,联系人列表将会从中受益。数据库将一个联系人的所有数据存储在一个单独的文档里的contacts 集合里。
在这个例子里,我们没有存储联系人的头衔或者性别,我们还添加了一些数据,而这些数据不需要应用到任何其他联系人。没关系——我们的NoSQL数据库不会介意,我们还可以随意添加或移除字段。 |
由于联系人数据在单独的文档里,我们可以用一条查询语句获取一部分或全部信息。全文搜索也变得简单;在MongoDB里,我们可以这样定义 contact 中的所有文本字段的索引:
然后执行全文搜索:
场景二:社交网络社交网络可能使用类似的联系人数据存储,但是它会根据功能集合扩展,比如关系链、状态更新、发送消息和”赞“。这些功能可能会根据用户需求来实现或者移除——无法预测它们会怎样演进。 |
另外:
NoSQL看来是个好的方案。它允许我们快速地实现存储不同类型数据的功能。例如,可以用单个文档里的 status 集合替换所有用户的过时的状态更新。
文档可能会变得很长,但我们可以获取数组的子集,比如最近的更新。每个用户的所有的历史状态记录都能被快速搜索到。 |
现在假设我们想在发布更新的时候引入表情符号选择。这涉及到给 update 数组里的新记录添加图引用。不像 SQL 存储,没必要把之前消息里的表情符号置为 NULL——我们的程序逻辑可以显示默认图片或者没有图片,如果没有设置表情符号的话。 场景三:仓库管理系统考虑一个监控仓库货物的系统。我们需要记录:
我们的数据需求:
我们需要一个具备强制数据完整性和事务支持的健壮存储系统。(当前)只有 SQL 数据库满足这些需求。 |
表现自己!我希望这些场景有所帮助,但是每个项目是不同的,最终,你需要做出自己的决定。(虽然,我们开发人员擅长于证明我们的技术选择,不管他们有多好!) 最好的建议:显露你自己尽可能多的技术。这些知识可以让你对SQL或者NoSQL做出一个理性和情感上公正的判断。祝您好运。 |
本文转自:开源中国社区 [http://www.oschina.net]
本文标题:SQL vs NoSQL:如何选择?
本文地址:http://www.oschina.net/translate/sql-vs-nosql-choose
参与翻译:李中凯, DJeeker, 奔跑的小草, 阳光的香味, 茶壶
英文原文:SQL vs NoSQL: How to Choose