数据库可以影响整体软件的架构设计，-- 那是当然！

数据库 DBA 在整体软件的成型的过程中大部分的单位都将这个职位定位成一个运维的职位。 当然既定的现实存在即合理，这也是无法辩驳的，但实际上DBA 到底应该不应该就是也给运维的职位，都2021年了，咱们的开始论论了。

我们先罗列一下大部分人认为的DBA 应该做什么

1 安装数据库，安装数据库高可用架构

2 执行开发给予的 SQL 包含 DDL DML

3 优化已经上线的SQL 语句，包含添加适合的索引，修改一些非逻辑性的SQL语句的结构

4 进行数据库整体性能的监控

5 解决各种数据库运行中产生的疑难杂症

6 为开发解决开发中涉及数据库的一些知识的问题

7 做数据库的备份和恢复，以及灾备问题

当然还有一些其他的工作，例如为业务部门写一些复杂的SQL， 或者对数据库的中间件安装操作，以及进行编程将一些工作自动化。

但现在的数据库和上世纪的数据库还一样吗， 还是ORACLE 选来选去还是ORACLE 的年代吗？

NO NO NO

按照盖老师（DBA鼻祖），名言名句，“这是一个数据库百花齐放” 的年代“，那既然是百花齐放的年代，那选择数据库，理解数据库的特点，并将这些特点与软件开发的架构设计融合，提高软件编程成型的速度，降低软件构造的成本，提高整体软件结构的抗击打性。这些可都是要 "DBA” 来进入的工作。

那我们看看新时代的DBA 到底应该可以在做点什么

实际上选择一个数据库参与到业务当中可以问如下的问题

1 在这个应用软件的预期中，业务预计需要存储的数据量

（这个问题其实是比较重要的，如果数据量大，采用的数据库采用那种形式在存储数据，例如分区表，分库分表，逻辑分表，sharding , 分布式数据库等等这些选择都与）

2 这个系统并发的用户是多少，多少用户会在业务高峰期登录系统，数量是多少

3 业务的重要性，与业务中数据的一致性安全性等，需要数据库的可用性是怎样的，例如核心业务在遇到问题后，如何保证业务，这决定了数据库的高可用的方式和成型

4 业务的特性是如何，例如是计算地理位置信息为主的业务，还是传统金融业务，或者以存储外部业务交换信息为主的业务，在或者是存储客户行为信息为主的数据集合信息，或者是风控为主的即时计算信息 等等。数据的原本的信息模式，数据的模式是怎样的？ 业务是以 OLAP 为主 还是 OLTP为主等等诸如此类的信息

5 数据供应的特性是什么，例如你的数据是读多写少，还是写少读多，数据的冷热数据是否明显。

6 应用程序开发的语言是什么，是JAVA ，GO ,.NET, PYTHON 那种程序开发的语言，本身这些语言对于使用哪种数据库本身也是有倾向的。

7 预算的问题，这当然是一个问题，目前整体的大环境的是 去掉 ORACLE SQL SERVER 这样的商业数据库，所以预算也是一个问题，目前开源免费的数据库大行其道，你怎么和你的老板交代，一年几百万和上千万的数据库采购的费用，是吧。

8 后续的问题的解决方案， 例如如果你选择了MYSQL 则后面数据的汇聚以及数据的在计算分析就是一个需要考虑的成本，或者采用POSTGRESQL ，MONGODB 后续的数据在分析和处理的方式和成本等问题，所谓不能顾前不顾后

9 数据的治理的问题，这个当然也是需要操心的问题，例如表的结构设计，到底那些字段是必须的，例如必须有记录的插入的时间等等，或者字段的命名规则，字段里面的值的命名规则等等。这也与后续的数据的交互和后续的数据处理有关。

所以一个应用系统设计中的数据库到底是不是可以左右整体业务逻辑的架构设计，此时还有多少人还有疑问？

此时还认为 DBA 就是个运维的岗位， 呵呵， TOO Young TOO simple。随着数据库的种类越来越多， 合理使用合适的数据库解决业务问题，系统架构的问题，早就应该被提上议程， 当然如果你说我们不需要，那倒是很有可能，因为目前还有一堆的单位，还在以使用一种数据库为荣，我倒是认为，这应该是这个单位的架构以及DBA 组的耻辱。

所以我相信，这就是一个“数据库百花齐放的”年代， DB们该提升提升自己，应对变化的环境，以及新的岗位需求，有这样岗位需求的单位，我想也不会太差。