I wanted to add my thoughts on this month’s T-SQL Tuesday. Haven’t heard about T-SQL Tuesday yet? Here are the details on it.
What is T-SQL Tuesday?
If you haven’t seen it yet, T-SQL Tuesday is the brain-child of fellow-MVP Adam Machanic (blog|twitter). It happens once a month on the 2nd Tuesday (different this month) and is hosted by a different person in the SQL community each time. The idea is that it’s kind of a rallying point to get a bunch of people to blog about a particular topic on the same day, giving a wide and varied set of opinions and interpretations of that month’s topic. The host then posts a wrap-up commenting on all the contributions. I think it’s a great idea and I contribute whenever I have time.
In my opinion DBA’s are the bridge between Development and Operations. DBA’s possess that level of Technical detail that can allow them to speak in SQL but at the same time talk to the end user/PM/Manager/Customer. A DBA that has these skills can be very effective in fixing problems when they arise. Many people joke about what DBA stands for, DBA = Default Blame Acceptor typically. Whether you accept the blame or not as a DBA it’s a fact that typically you will have many fingers pointed at you when something goes wrong. Typically in the DBA world you are guilty until you prove otherwise. To be able to handle situations that arise regardless of where the blame lands is why you need DBA skills.
DBA’s typically possess 2 very important skills that set them apart. Being able to see the 30,000 foot view, like it or not the DB is usually the central source for many applications and processes in a company. The DBA has to understand this and know how lots of different pieces work together. They never have the luxury of only writing there one small piece of code that fetches bacon all day long (apGetBacon stored proc would be nice) . They need to understand the server, network and code to know how it all works together.
DBA’s are usually very patient as well, having the finger pointed at you constantly for performance problems or size issues (I’m speaking of hard drives of course) makes you learn to be patient and work through the problems. Most of the time it does appear to be a database issue since that is typically what is central to all the different applications in the company so the DBA has to take the time to find the real problem and to defend the database.
It’s a simple fact that the DB is one of the most critical components of many organizations. This fact alone tells us that DBA skills are very necessary to help improve move the business into the future. While this is a great question to ask I hope that businesses start focus on when do we need a DBA to handle one of our most precious commodities?