| 面向文档型数据库存储的是文档、属性和XML。面向集合型的数据集提供了更适合面向对象编程语言的特性。关系型数据库的特性是用表，行，列(面向列型)来组织数据。SQL查询操作通常返回的是指向包含特定列的某行或某些行的集合的指针。面向对象的数据库之所以出现是由于面向对象的编程的流行，但目前为止(以及将来很多年里)关系型数据库仍是数据存储模式里占有霸主地位。面向对象型数据库也是 NoSQL 数据库吗? 对象关系映射(ORM)框架的兴起将面向对象编程和大多数关系型数据紧紧的绑到了一起。 NoSQL 数据库里的数据通常是存储成对象、key/value、或数组(tuples)形式。 NoSQL 数据库的查询操作通常由编程代码或一个接口完成。 在一次邮件交流里，Charlie Caro 对我说了下面的话：”如果 Facebook 需要去管理 100,000,000个用户的个人信息，一个分布式的、不依赖于环境的，key-value形式的存储模式是最适合不过了。在这样大数量的用户里查询会没有问题，但只要一个用户的更新操作就可能让传统的数据库过载宕机。多用户读数据时一个用户更新数据，这需要并发控制。在多数情况下，NoSQL方案之所以能吸引它的用户群的原因是它的易于安装和使用的特征，SQL数据库需要较多的运行条件(schema 等)，但正是这些schema方案给了并行关系型数据系统的高性能。易使用的好处更多的是体现在编程开发的时候。今天的许多程序员都更倾向于使用脚本语言，而不是相同功能的更安全的静态类型检查的编译型语言。脚本型语言只是容错性强和易于上手，有些软件能把这些脚本程序编译成.NET/Java字节码来提高运行性能。” 我和他都认为，所有的这一切都是为了让我们在工作中有更好的工具使用，而且从来都是这样!当有螺丝刀时谁还用锤子去钉螺丝钉。 在”SQL数据库的终结 – 第二篇(共三篇)“中，我们以同样的视角来看一看目前已经出现的一些开源的或非开源的NoSQL数据库。之后在”SQL 数据库的终结 – 第三篇” 中，我将会告诉大家一些因特网上关于NoSQL的资料，过去和将要发生的事件，以及一些相关指导。 数年以后，我估计我们大多数还是要依赖于关系数据库和SQL。我当然有愿望，我将会不断的研究寻找更好的方式去弱化和封装数据访问操作。一直以来，任何工程决策都是跟用户和业务需求相适应的。对于以后的软件工程来说，我相信，我们一定会找到一个合适的非关系型数据存储产品。你是否正在使用非关系型数据库呢?你是否已经放弃了SQL和关系型数据库呢?你是否正在把你的数据转移到一个公共的或私有的云数据库里呢?请发表评论。 编程就是人生! |
