SSWUGtv
With Stephen Wynkoop
Security is an area of change. The goals are still the same. How we implement our security continues to evolve along with our software platforms. On todays show, Patric Townsend continues his series on security with the question, What’s the difference between dual-control and separation of duties?
Watch the Show
DBA Role Clarification
Not every business utilizes a DBA with the exact same job description. I think that may be causing some confusion in this series on the changing role of the DBA. Some have written in asking for clarification. So, I’ll try and wrap up today with some history of DBA roles and how they have changed over time.
Your data and therefore the systems supporting the data are a very expensive resource to build, manage, maintain and protect. Historically, only companies using midrange or main frame computers could afford a sophisticated database system. Those systems, because they were enterprise wide resources, and highly technical, were restricted to a few technicians known as DBAs. Developers could access those databases. But the DBA was responsible to create, model, mange, secure, and protect those resources so that all users had the necessary performance and security.
As those systems grew, companies found a need to extend their DBA resources sometimes to entire teams in order to provide adequate throughput to those resources. However, the DBA team was an authority unto itself. Developers simply utilized the resources granted, and rarely managed database resources.
DBAs were responsible for query tuning and system optimization. Developers might submit queries, but DBAs were the final authority of released database code.
With the advent of PC based relational databases this wall began to fall. As the PC Based systems grew in power and scalability, no longer being restricted to single user applications, the impact of the developer on database systems began to break down this wall of the DBA silo of power.
The DBA silo still exists in many companies today. Primarily you will see this methodology used on large systems using Oracle or DB2. These are systems a developer will quickly hang themselves on because they have so many capabilities beyond the SQL syntax that systems such as SQL Server manage for you. It is a different product for a different purpose, requiring higher skill sets than a developer has time to maintain.
Because tools like SQL Server or MySQL, Posgress and others provide adequate performance, often beyond that needed of all but the most demanding application, and because those tools have taken the best average approach to self manage rather than using highly trained technicians, companies have been able to reduce the need for highly skilled, expesive DBAs.
The DBA role has been reduced in some operations like Dana shares today of simply being a Disaster Recovery manager. In this world the DBA is not in tune with the database schema and how to make it perform.
Another trend that was really big in the 1990s was the use of Stored Procedures. This provided the DBA with a set based coding language that could be compiled and optimized to perform SQL queries. They could be tuned and optimized as well as providing a separation of concerns. Developers writing applications that used stored procedures would not be impacted when the underlying schema was modified as long as the stored procedure continued to work the same way. This was a great feature providing stability for application development.
Today, with the rise of multiple system based software, we no longer want to put all of our eggs in one basket so to speak. So, a stored procedure can only reside on one computer…the computer where the database is hosted. Having all your business rules encapsulated in stored procedures provides one point of failure, and scalability issues. Cloud based software, on the other hand, allow you to scale out to multiple servers performing the same task. Stored procedures do not provide the same value in this world. No longer do you need high cost DBA to be the keeper of business rules.
I can see a great deal of confusion in how the role itself has changed. There are the current high end DBAs on the one end managing large systems getting top dollar. There are also those individuals called a DBA who are little more than an operations individual.
I believe there is a third individual having evolved out of this group. That would be a Developer DBA. This individual is the person who is highly skilled in database schema design. They also write application code in the Data Access Layer. Instead of writing SQL code only, now they are writing code in Java or Dot Net providing direct access to the database. Sometimes they are also responsible for the translation of the database objects into business objects through Object Relationship Mapping.
Again, because this is more work than an individual may do, they may supplement the work to be done by using ORM generators or mentoring developers with appropriate Data Access techniques. This is the person who keeps developers from writing code resulting in SQL Injection, or pour performance because the embed SQL strings in their applications.
One last path DBAs have taken is to move into Data Warehousing and Business Intelligence. My guess is that this is an area for which companies are hiring. I see very few companies writing their own database applications that need a full time DBA. The BI DBA is probably the closest thing to the DBA of yesteryear as a resource group unto itself shared by an entire company.
Dana Writes:
“DBA is the most intimately in tune with the relational data structures”
That’s just not true. A DBA has one job and one job only, make sure they can be recovered. As a bonus, blindly collect statistics at a set time and tell the application developers, statistics need to be collected. If they are important and need to be done at a certain time, you do it, here is how. The application developers need to understand the database structures, the DBA just doesn’t care what you do in the database.
Auto-generated DAL
These CRUD tools are just worthless. Some developers don’t know how to write SQL. They need someone to do that for them. More than likely, there is someone (or two) in the DBA group that has those skills. I don’t think that makes it a DBA Role, I think it just means they can write SQL better than some “software”. Often I have developers tell me “it’s slow” and when I look, I see a poorly written query or a really fast query running millions of times. When I tell them to, “change it to this” they tell me they can’t because they don’t write SQL. From there, I tell them don’t come back to me with “it’s slow” again. I’m going to give you the same answer.
By rule, DBAs are supposed to be lazy. They are supposed to make the complex look simple and the automate the mundane. I hope that changing (or writing) application code never falls into the DBA role. However, I’m sure it isn’t all that hard, after all, developers can do it, how hard could it be?
If you made it through this whole newsletter, I appreciate your patience. This is based on my experience and conversations with a number of DBA professionals over the years. I’m sure many of you have had similar or very different experiences. But, as a whole, I think you’ll find that the role of the DBA which used to be quite stable has morphed into completely different skillsets.
Cheers,
Ben
$$SWYNK$$
Featured Article(s)
Secrets to Taking Command of Your Own Performance Review Part II
Last interview and article, we quickly mentioned the Personal Business Commitment tool as a great way to communicate your goals and commitments to your manager. But what makes up a Personal Business Commitment plan? Who creates it? Who approves it? How does it fit in the performance rating process?
Featured White Paper(s)
How to Use SQL Server’s Extended Events and Notifications to Proactively Resolve Performance Issues
read more)