Tuesday, August 25, 2009

A DBA or a Database Developer?

I often think if the above two roles can be completely separated. From my point of view I would say that this is not 100% possible.

Of course, DBAs are not developers and developers are not DBAs.

The DBA is responsible for the environmental aspects of a DBMS like the databases integrity, backup, security, installation of new DBMS software, etc.

The developer is the person who designs databases and other related database objects. Is the person who writes application code against DBMSs using T-SQL and other data access technologies.

There are many cases where the developer cannot perform the tasks the DBA can. Examples of such tasks are: Implementing High Availability solutions, DBMS security and so on.

Also, there are cases where the DBA cannot perform tasks that the developer can. Such tasks can be: Implementing T-SQL queries and other database objects (i.e. stored procedures and functions) that access and modify data.

Though, as the below figure graphically illustrates, there is an area of responsibility which is common for all the DBMS-related professionals in terms of common tasks or tasks which require the interaction of both DBMS professionals:


As an example, consider the task of Performance Tuning. In this case the DBA will monitor the DBMS instance for identifying bottlenecks on the memory, disk, CPU and network subsystems which are might caused by the operation of the databases under that DBMS instance. If the DBA discover a bottleneck on the pre-mentioned subsystems then is able to proceed with optimizing the DBMS by upgrading the subsystems causing bottlenecks (i.e. add more RAM) or addressing the issue relatively independently.

Though, doing only this is not really enough for performing an efficient and comprehensive performance tuning. Imagine the case where the DBAs runs a trace and finds that a specific database query which exists in a stored procedure and manipulates data has slow performance and needs to be rewritten. In this case the DBA will discuss this with the designer (developer) of the stored procedure in order for the latter to perform the required analysis and then redesign/optimize the stored procedure accordingly.

The above example indicates that performance tuning is one of the DBMS tasks which require the cooperation of the DBA and the Database Developer in some of its aspects.

Another example within the above context is writing T-SQL queries. Sure, the DBA writes T-SQL queries for administrating the DBMS instance whereas the developer writes T-SQL queries for manipulating data but still, in many cases they both write similar code. So under this context, the DBA should be capable of writing T-SQL queries with ease, not for manipulating data within the databases (this is the developer’s job) but for performing automated, administrative tasks. An example for performing automated tasks in a DBMS is to design and implement a stored procedure which can be executed on a scheduled-time basis.

Lately, Business Intelligence (BI) became very popular. To this end, now there is another DBMS role; the BI Developer.

The BI developer is the person who works with business intelligence technologies, in the case of SQL Server, like Reporting Services, Analysis Services, and Integration Services. Is the person who analyzes data in large Data Warehouses and transforms row data into knowledge.

Yet again, as the below figure graphically illustrates, there are still common tasks among the DBA, Database and BI Developer roles which require the interaction of all roles:

Like in the first example, a comprehensive performance tuning would require all three DBMS professionals working together in some of its aspects. Also, all three professionals must be capable of “reading” and writing T-SQL queries. Additionally, all three roles should work together in the case of data archiving and so on.

My conclusion is that even though each DBMS role has its own, genuine areas of responsibility where only professionals under that specific role can perform the related tasks, there will always be some tasks which will need the cooperation of all three (or even more) DBMS roles.

Of course, if a person has expertise on all the aspects of a DBMS operation (Administration, Development, Business Intelligence, etc.), this would be the best case scenario! :)
[Ads]
Check out my latest eBook on SQL Server:
Tuning SQL Server - Ebook

Easily secure your SQL Server instances! Try out DBA Security Advisor!
DBA Security Advisor for SQL Server by SQLArtBits
DBA Security Advisor was developed by SQLArtBits. The tool was being carefully developed for an entire year and it contains comprehensive security checks and recommendations based on proven SQL Server security best practices. Feel free to download and use the Community Edition which is free and if you find it useful, you can consider upgrading to the Enterprise Edition!

Artemakis Artemiou [MVP]

Author & Editor

Artemakis Artemiou is a Senior SQL Server Architect, Software Developer and Microsoft Data Platform MVP. He is also an author, regular blogger, president of Cyprus.NET User Group and CY Country leader of INETA-EU. He is also the creator of DBA Security Advisor and In-Memory OLTP Simulator. Artemakis is a frequent guest author of worldwide well-respected online journals where he writes articles focusing on many SQL Server topics.

Reference: The SQL Server and .NET Hub (http://www.sqlnethub.com)

2 comments:

Andreas said...

Seggration of duties is a must in large organizations for many reasons (security, auditing etc).
In small organizations we find 1 person doing Db administration and development work.
However in large organizations developers should not have access to production and Dbas should focus on the availabiity and performance of their critical systems.

Artemakis Artemiou [MVP] said...

Hi Andrea,

Thank you for your comment.

I totally agree with you that segregation of duties is totally necessary in large organizations. Well, it is also necessary in small organizations but of course, due to budget limitations, etc., it is less applicable.

Large organizations have the capability of having specialized personnel performing specific tasks. Based on this post's concept an example is a DBA strictly performing administrative tasks on the DBMS and a Database Developer designing/implementing data applications and designing databases.

However, even though segregation of duties in large organizations is a must, segregation of knowledge sectors among the technical personnel within an organization (regardless of its size) cannot be so strict. For example, if a DBA knows how to design a stored procedure, it will then be much easier for him/her to have a technical discussion with a Database Developer regarding an expensive stored procedure which was identified during a performance monitoring process that it generates a very high I/O. Similarly, if a Database Developer understands what Replication is, he/she will be able to better design a database and data application for making it easier for the DBA to set up the Replication process later and so on.

What I am trying to say (and this is just my personal opinion :) is that the more the DBAs and Database Developers know, the easier is to cover any knowledge gaps having to do with the design, implementation, operation and maintenance of a DBMS instance and the databases it supports. I believe that the same stands for the entire field of Information Technology.

Cheers,
Artemakis