无论多么辉煌的数据库技术，也有被淘汰的时候，我们不免要经历一次“霸王别姬”。
SQL 的发展起始于 E.F.Codd 博士1970年六月发表于计算机协会的“通信”上的一篇论文， “大型共享数据库的关系模型“。当时他和他的在IBM工作的同事 Donald Chamberlin 和 Raymond Boyce正在研究一种查询语言(最初叫做SQUARE, Specifying Queries As RelationalExpressions的首字母缩写)，并于1974年以论文”SEQUEL:A Structured English Query Language“将此成就推向顶峰。从此以后，SQL就成了关系数据库系统的最主要的语言。近些年，软件开发业内出现了一些体系框架和架构，主要目的是试图隐藏（或完全放弃）直接使用SQL和关系数据库，让开发人员能够在应用开发中专注于用户界面，业务逻辑和平台支持上。同时出现了一批被认为是关系型数替代品，称之为”NoSQL”的数据库。难道我们能够成为 SQL和关系型数据库终结的见证人吗？
在一个由Mike Riley主持的十二月 DDJ podcast 访谈中，我被问到：“随着ORMs(Object Relational Mapping对象关系映射)的流行，有些软件开发者们认为SQL已经失去其价值了。你对这种观点有什么看法？”我整个新年假期都在想这个问题，思考这个问题所隐含的意义已及ORM的未来，我花一段时间研究了一下像 Ruby on Rails Active Record 和 Hibernate 这样的框架。这些框架仍然需要开发人员掌握关系数据的设计、开发和维护等知识。 Microsoft所开发的LINQ(.NET Language Integrated Query)也只是减少了编程语言和数据库语言之间的不兼容问题。
“NoSQL运动”和分布式数据存储（Cloud based data stores）都是致力于彻底的将开发人员和SQL语言和关系数据库之间的依存斩断。一些程序员认为 NoSQL 运动是一种全新的感念。面向对象式数据库（Object databases）最早出现于19世纪80年代， Ray Ozzie 于19世纪90年代最早将它商用于Lotus Notes的文档数据存储业务。
Charlie Caro, 资深软件工程师，在美国 Embarcadero 开发 InterBase SQL 数据库引擎，他告诉我：“在以前，人们普遍认为，不对数据的并发操作进行控制的数据库基本不可能被大家广泛接受。但Ozzie认识到，分布式、可复制性和易于安装的特征所带来的好处远胜于在管理文档数据和消息时很少能遇到的并发更新冲突控制所带来的好处。而且，如果文档数据如果需要确保被正确的修改、不能丢失数据，我们可以把配置切换到并发控制状态上，这是可选择的。但缺省状态是不考虑更新冲突控制的。”
NoSQL, 根据WikiPedia上的解释，是 “一种泛称（umbrella term），指那些非关系性的、定义不是很明确的数据存储仓库。“这个术语最早是 Rackspace 公司 的员工 Eric Evans 发明的。在他上年十月发表的博客里出现了NoSQL (现在普遍认为是 Not Only SQL 的意思) 这个词。这篇博客里真正的闪光点是”我们之所以要寻找一个其它类型的数据库的根本原因是想解决关系型数据库存在的各种弊端。“Adam Keys 在他的博客The Real Adam blog post提供了另一个相似的术语：”Post-Relational”。一些 NoSQL数据库还把消除那种关系型数据库对计算机资源、内存占用的问题作为一个目标。NoSQL的其他目标还包括：弱化与编程语言的关系，使用Web技术和RPC调用方式可访问，以及可切换的数据查询方式。
在最近的一篇博客“关于NoSQL的讨论其实与SQL无关”里 Michael Stonebraker 教授将 SQL 和NoSQL 数据库进行了对比。SQL 和 NoSQL 数据库可以通过下面的几个特性和性能进行部分或全面比较 (注意：应该有更多的特征可以添加到下面的列表里。欢迎在评论里追加你认为能够区别这两种数据库的特征)：
横向和纵向扩展能力 – 关系型数据库(传统的数据库)通常部署在一台服务器上，通过增加处理器、内存和硬盘来进行升级。部署在多台服务器上的关系型数据库通常是依赖相互复制来保持数据同步。NoSQL 数据库可以部署在单服务器上，但更多的是部署成云状分布式 (NoSQL:分布式和可扩展的非关系型数据库系统)。
列，key/value存储，数组(Tuples)存储 – 关系型数据库通常是有表或视图里的字段构成(固定的结构，用各种操作相互关联)。NoSQL 数据库通常存储的是一对键值或 数组式(Tuples) (结构不固定，只是一个有顺序的数据队列)。 数据的内存和硬盘使用 – 关系型数据库通常是驻留在一个硬盘内或一个网络存储空间里。SQL查询或存储过程操作会把数据集提取到内存空间里。一些 (并不是全部) NoSQL 数据库可以直接在硬盘上操作，也可以通过内存来加快速度。
面向文档型（Document-Oriented）, 面向集合型（Collection-Oriented）, 面向列型（Column-Oriented）；
面向对象型（Object-Oriented）, 面向有序集合型（Set-Oriented）, 面向行型（Row-Oriented）。
面向文档型数据库存储的是文档、属性和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和关系型数据库呢？你是否正在把你的数据转移到一个公共的或私有的云数据库里呢？请发表评论。
