应用系统设计数据库到底应该站哪？

DBA，通常给项目经理或者开发人员，系统架构师的印象，大概可以总结出以下几个词 ，不重要，管数据库的，装数据库的，老是找麻烦的，我们架构设计尽量不使用数据库或不强依赖数据库,  没什么用，和项目有什么关系？虽然这些词比较负面，但实际上不少上述人员，对DB的印象可能就是如此。

为什么？因为部分公司的DB人员和运维人员没有什么区别，这就是导致上述词汇和印象的原因之一。

另一个原因是MYSQL的崛起，是DB被轻视的另一个原因,为什么是MYSQL的崛起。在大部分以MYSQL为数据库使用对象的公司中，除了部分公司，大部分公司对MYSQL的使用基本上已经忽略的数据库在系统应用方面的设计，由于MYSQL本身的数据处理提供的功能，要比其他数据库弱，所以系统应用设计中，大部分的数据处理都，业务逻辑实现的部分都在MYSQL以外的位置实现了，例如程序本身将数据库看做是一个数据存储的介质，只关心他能提供多少QPS，TPS，而其他的都可以通过程序及程序架构来实现。数据库的功能被程序剥离了，使得在程序设计中数据库逐渐偏向“硬”方面的设计，（读写分离，分库分表，性能优化，规范等）除此以外就是因为使用MYSQL而带来的，本来一个物理库能实现的事情，而变成多个MYSQL 数据库来承担，这就更强调程序的设计，而非数据库的设计。

所以DB人员的地位在系统设计领域方面，基本上找不到话语权，或很少有话语权。

在互联网领域，很少听到有数据库方面的对于业务和业务逻辑方面的人才，而在程序层次方面，由于数据库的弱化，带出一批的中间件和程序架构，业务逻辑实现等方面的软件开发和架构人才。

所以DB在这样的情况下，在业务逻辑架构层次可以“指手画脚”的space很少，存在感也不强。反倒是有这样一种说法，MYSQL 的使用导致软件架构和设计方面的人才在逐渐进步，数据库在有些大型互联网企业，沦为容器化的存储设备而已。

而随着近几年各种数据库不用的声音，数据库需要被设计，在软件方面的设计又有变强的节奏， 例如POSTGRESQL , MONGODB， 或者一些偏门的cassandra, 时序数据库，图数据库等等，各种解决某个领域，或者一个数据库全能的产品又重出江湖，那DB 在整体的系统设计中的话语权，应该被“召回”。

DB在整体的系统架构中的设计重新被提上了议程，以POSTGRESQL为例，由于功能方面的强大，尤其和MYSQL相比，无论在某个专项领域，或者数据库本身领域都有可圈可点的功能卖点， 或者MONGODB在专项领域的无可动摇的地位，都导致DB又开始不再以一个数据存储的基本容器存在，而是提供应用系统中的更重要解决问题的角色，程序设计可以变得更简单，数据库又可以承担一些程序设计中的附加功能点。

举例：如果我们将大批的数据进行模糊值得匹配，在数据库中处理比较困难，可能会借助第三方产品例如elasticseach ,或者程序将数据读入缓存，在进行模糊匹配，这样的情况下，例如MYSQL 在这方面是没有话语权的，所以系统架构设计中，自然就不会考虑他成为解决问题的必选项，而是无关项甚至是障碍项。

而利用POSTGRESQL 中的某些功能，在数据库本身就可以进行大量的模糊数据处理，则如果在应用程序设计中，数据库就承担了程序架构设计中的需要承担的功能，那此时数据库就成为问题的解决者，成为应用系统的设计中的可选项，或者必选项，则此时DB可以发声和主导占比必然会提高。

又如，目前微服务为前提的软件开发中，各个系统中的交互变得不在数据库内部进行，而是在程序和程序之间进行，程序和程序之间的数据交互的格式是什么，或大部分是什么，此间要求的数据的存储和处理的速度，等问题，MONGODB 就成为数据库能给的解决方案。

所以流行什么，并不意味着是好的或者合适的，存在当然有存在的道理，但当发现更好的时候，能更多去选择和尝试，或许既能提高自己，也能改变当前DB在整体行业的话语权和重要度，找到自身在行业中的可以站到的位置。