有的选是一种幸福

随着计算机互联网越来越贴近生活，越来越方便生活，越来越让生活更加有质量，更加自由和放松，操作系统和数据库作为计算机软件世界的巅峰之作，它们的发展也与时俱进，除了传统的关系型数据库的不断增强和发展，还诞生了许多新的数据库类型，针对特定的应用场景，这些新诞生的数据库更加适用。

如果，世界是多样的，那么用来描述这个世界的数据也一定是多样的，单一的存储模型和数据结构往往在处理某些类型的数据结构时，显得很笨拙。

用平面化的数据结构来描述一般的对象，基本可以满足需求，这也是传统数据库描述和存储数据最擅长的场景，任何复杂的对象，理论上都可以用一个或多个平面化的数据结构来描述。但数据不仅仅是用来保存的，还会有增删改查的需要，不仅要能满足这些需要，而且还要兼顾到效率。要同时满足这些要求，用平面化数据结构来描述非一般对象的数据库就有点力不从心了。

要干啥就准备啥，这些由目标和需求决定，选择适合的工具的重要性在开发应用软件的过程中体现的非常突出。杀鸡焉用牛刀。没有最好的，只有合适的。

从我多年使用数据库的经验来看，数据库技术越来越丰富了，家族成员也越来越多了。现在的数据库不仅有擅长处理平面化数据结构的，还有擅长处理更简单结构的数据库，更有擅长处理树形关系对象和不规则关系型对象的数据库。这些库的存在极大丰富了数据库的功能，在不同的场景使用合适的数据库变得从未如此重要。

因为之前没得选，再笨拙的操作，也只能这么用。很无奈，因此，之前很多人还会以书写极其复杂的SQL语句为能事。我从来不这么认为。尽管我也能写出复杂的SQL语句，我曾花了一周的时间，把公司一个项目的后台统计功能用SQL完全实现了，还捎带完成了一个计算分成的查询。但我并不认为这有什么好炫耀的，我想要强调的是，完全用SQL在关系型数据库层实现那些统计的设计是欠缺考虑的，这样做的同时，应该在架构上有足够的支持，否则，这将会带来影响业务和客户体验的一次不得不做的代价极大的架构调整。这是给项目挖了一个坑，虽然，这貌似不需要人来承担责任，但目光所及的地方，我还是看到了陷阱的存在。也许扯得远了。我们还回到数据库这个方向上来。

我们这里要说的就是：请关注不同的数据库提供的算法更适合哪些对象和场景。不管多巧妙的SQL都改变不了数据库的内在数据结构和提供的算法，我们提交的SQL最终都会转换为数据库本身提供的那些算法，使用合适的存储结构和算法才是我们选择数据库时的首要考虑。

我们大部分人所写的代码都是业务代码，更底层一些的就是框架代码，不排除有部分人能够在业务代码或框架代码里灵活的使用各种数据结构和算法，我想这部分人一定愿意写些更有意义的代码——能体现思想和思维，有足够的抽象性和普适性的代码。这些代码完成的代表作就是操作系统和数据库，以后一定会有更多的领域需要类似的软件产品。所以，优秀的人永远是稀缺的，永远不要认为，我如此优秀，怎奈天妒英才。其实，我们都知道怎么一回事了。

下面我总结一下：

1. 普通对象，传统关系性数据库是最佳选择。
2. 频繁访问和修改的对象属性，键值对数据库和文档型数据库的拿手好戏。
3. 树形结构，网状结构，有向图对象，图数据库的用武之地。

在之前那个匮乏的年月，一些需要从根本上解决的事情都是要算法工程师来完成的。现在只要把这些库用起来，写业务代码永远无需关心计算机世界最核心也最晦涩的算法，这是一种幸福！