当前，在很多公司中，不管是IT公司还是非IT的企业，都会配备DBA这样一个职位，负责管理相关的数据库。然而，很多时候，DBA这个职位的位置却有些尴尬。

　　一般，一个企业的IT团队会分为两个部分，一部分我们可以称之为基础设施或者基础架构(Infrastructure)团队，他们会负责管理企业的计算机硬件、服务器、网络设备、电话等等;而另一部分一般称为应用开发，负责与软件开发相关的工作。

　　那么DBA应该归属于哪个团队呢?从程序员的角度来看，DBA当然应该归属于应用开发团队。然而，实际情况并非如此，因为DBA要负责管理数据库服务器，所以很多时候都会被划分到基础架构团队。而且，一般来说，数据库的结构设计工作，都是由应用开发团队来完成的。DBA并不会根据应用开发的需要来对数据库服务器进行规划，而只是简单地保证有足够的数据库空间供应用开发团队使用就好了。

　　同时，开发团队也不一定认可DBA称为开发团队的一员，当前很多企业都在搞EA(Enterprise Architecture)，也就是企业架构，期望IT的架构能够和业务架构相互匹配，从而让IT能够更好地为业务服务。在这里，IT的架构研究更多着重在企业的各种应用服务器，重点也在于应用开发方面，而并没有把数据库的架构那纳入进来，或者说没有把它提到一个足够高的位置上来。

　　另外，现在有了云技术，越来越多的企业会把数据放在云存储上，从而降低公司的成本，如果真的把所有的数据都放到云端的话，那么DBA这个角色就没有在企业中存在的必要了。

　　然而，我们是否认真的考虑过，数据库的架构是否要和业务的架构匹配呢?或者说，DBA是否需要了解业务，才能够更好地完成自己的工作呢?

　　如果深入了解数据库的运行原理之后，我们会发现DBA了解业务是非常必要的，不妨举例说明：

　　大家都知道，在Oracle数据库中可以设置很多表空间，而不同的表空间可以放置在性能不同的存储设备上，那么在哪里放置什么样的表空间，而在表空间里存储什么样的数据就有讲究了。

　　比方说对于经常会用到的数据，像一些基础数据，就需要放在性能高的地方，而不会经常使用的数据，像日志、备份数据，就可以放在性能低的地方。

　　比方说有时效性的数据，对于最近的数据或者说今年的数据，就应该放在性能高的地方，而十年前的数据，可能需要归档了，就可以放在性能低的地方。

　　再比方说各种数据存储的问题，各个部门所要使用的数据表之间都会有很多关系，而把这些数据存储在相近的位置，那么在获取数据的时候就会比较快，而如果散落在各个角落，那在获取数据的时候就比较麻烦，性能也低。

　　另外，还有一些Oracle专有的技术，像各种类型的索引，对于各种不同的数据，采用不同的索引，最终的性能也不同;还有对数据表的分片(partition)技术，也必须在了解了业务之后才能够作出比较合理的选择。

　　由上面的内容，我们可以看出来，想要真正保证数据库的设计和运行的性能，DBA非常有必要了解业务的一些信息。

　　而当前的很多DBA的工作方式却很无奈，对于表空间，他们可能只会建立一个非常大的表空间，然后把所有的应用数据都放在一起;在开始的时候，也没有办法对数据库的存储设备等进行有效合理的规划，根本的原因还在于他们无法了解到业务的信息。

　　综上所述，作为DBA，需要更多地参与到系统的建设中来，而不是单纯地对服务器进行管理，而且需要了解更多的业务知识。