数据库可以说是通用软件领域中最挣钱的产品了，这些年的市场也是相当热闹。这个时刻说数据库会消失，是不是有点胡扯了？

且听我一家之言。

数据库的任务主要是解决数据的存储和计算，只要应用软件还在做，这些功能当然不会消失，但是不是还能作为软件产品独立存在和销售，那就难说了。

那么这些功能会跑到哪里去？

会融合到开发工具中，以后的应用开发工具（或程序语言）就会带有数据库的这些功能，开发出来的应用就拥有数据存储和计算的能力，用户不需要再单独部署和购买数据库。

类比一下，照相机作为一个独立商品，现在基本上消失了。但它的功能仍然在，只不过融合进了手机中。

为什么会这样？

因为数据存储和计算是无处不在的，特别是数据计算，在应用的各个环节都需要。事实上，应用中的业务逻辑从技术上讲就是某种意义的数据计算。到处都要做数据存储和计算，而目前只有数据库能把这件事做好，碰到这些事都要再和一个独立的数据库做接口打交道，就非常麻烦，会导致应用程序很难写。只有把数据库的功能融合进应用程序才能让开发更轻松。

类似地，手机应用处处都需要照相、分享图片、扫个码之类的。如果做成两个设备再传输，那就非常麻烦。要在一个设备中把这些事都能做了，就能连贯通畅。

那为什么现在不这样？还等什么？

因为现在的主流程序语言，如 Java 和 C# 以及 C++ 等，都还做不出好用的语法来承载数据库功能，需要发明新的程序语言。

这就像早期的手机操作系统能力不足，无法承载照相机功能一样。直到智能手机出现后，这件事才成为现实。

其实，作为独立软件的数据库也不是天生就有的。早期的应用程序中，程序员直接用文件来存储数据，计算也就是自己写代码搞定。时间长了，总有一些重复的功能，于是人们就抽象出一些常用的 API 来调用。再然后，人们发现需要专门的程序语言来操纵这些事情更方便，而新的语言难以融合进现有开发工具中，于是把数据库独立出来（不过数据库独立出来的原因并不只这一条，这里不深入探讨了），几经竞争，程序语言也基本上统一成 SQL 了。

这个过程中，事实上一度曾出现过融合数据库功能的开发工具。三十几年前，有 dBase、FoxBase 以及 FoxPro 都是属于此类，数据库功能和应用逻辑一把抓，微软现在的 Office 里也还有 Access，只是不太常用了。但后来，C/S 结构流行起来，把程序天然分成前后两截，而这些开发工具适应不了新结构，就逐步被淘汰了。

C/S 结构下也曾有个著名的开发工具叫 PowerBuilder，它有自己程序语言，其中已经有个较强大的 DataWindows 对象，如果再发展下去，很可能再次成为前端拥有数据库功能的开发工具（程序语言）。然而，C/S 结构又演化（不知道是进化还是退化，只好用演化这个词）成 B/S 结构了，PowerBuider 这种工具又不适应了。结果是，Java 占据了 B/S 应用开发的主流（其中原因很复杂，这里也不探讨了）。一方面人们已经比较习惯数据库独立化，从 C/S 迁移应用时也继续延用这种结构；另一方面，Java 这种语言很难发展出融合数据库功能的语法。于是，数据库就继续独立下去了，这一轮持续了很长时间。

分久必合，现在又该回来了。

随着应用的复杂化，数据源的丰富化，基于 Java 开发应用越来越麻烦。Java 本身不擅长做数据库所做的存储和计算事务，但把这些任务压进数据库也很麻烦。Java 中搞出 N 多框架类库试图封装数据库处理和运算，但也只能解决一小部分问题。近年来，Java 也发展出不少可用于集合类数据计算的类，比如 Stream 等等，也是在试图把数据库功能融合进程序语言，效果依然不太好。另外，嵌入式数据库也开始有了，所有这些，都是希望在应用逻辑环节而非数据库环节能够实施更多的数据库式的处理和计算。

甚至，前端也应该有数据库功能，只是之前在浏览器上太难实现。而现在 APP 时代又成为可能了，事实上 APP 中也真地开始使用嵌入数据库，但是隔了一层皮还够不方便。

所以，我们有理由预计，假以时日，业界会发展出新的程序语言，在保留原有业务逻辑处理功能（过程式程序）外，再把数据库的功能也融合进去。这时候，单纯作为软件产品的数据库就没有必要存在了。

在某些巨大的专业应用中，数据库还可能会分离出来独立存在，就像有些专业人员还需要专业的单反相机，但绝对大多数人用手机足够了。绝大多数应用也只要用开发工具中融合进的数据库功能就足够了，数据库作为一个软件商品，将会只存在少量极为专业的场景中，不会再是一个高销售额的产品。当然，这可能是十年以后的事情了。