THE SQL Server Blog Spot on the Web

Welcome to - The SQL Server blog spot on the web Sign in | |
in Search

Buck Woody

Carpe Datum!

Aren’t DBA’s Just System Admins for Databases?

Last week I ran into an argument I’ve had since I left the mainframe space decades ago. A developer told me “DBA’s don’t design databases.” The inference was that DBA’s (i.e., Database Administrators) only worry about hardware, security, OS, database backups, things like that. He seemed amazed that a DBA would ever do “data” work.

It may be the name. Perhaps the “admin” part confuses developers. Also, it is true that in some shops, a systems admin does double duty with Windows, SQL Server, and perhaps even mail and web admins.

But there are a LOT of DBA’s, or as the term I like to use, “Data Professionals”, that actually DO get down in the trenches and design databases, write Transact-SQL code and stored procedures, and do almost everything in the database other than write middle-tier or User Interface (UI) code. Some I know even do that.

So what if there is a miscommunication on this? Well, the ramifications can be huge. For one thing, there’s a lack of respect. That’s not called for ever, no matter what anyone’s role is. Also, one of the most impactful areas in a database is the design. When a DBA is asked to export data, tune a process, or troubleshoot an issue, it invariably involves the design. So when a DBA doesn’t get to do the design, they have to live with the results. And anything you’re responsible for when you don’t have the authority over is a recipe for stress.

Another issue is that DBA’s “inherit” all kinds of data structures form around the company. From Microsoft Access to Excel, to amateur Business Analysts creating databases in the Express Editions, they deal with bad design day after day. The newer “modeling” languages that are coming into vogue will make this problem much worse. These languages do not take scale, extensibility, security or performance into account – they just make sure that the data ends up in the right place for that particular design, which is a recipe for data disaster when the “small application” the developer writes becomes a “mission critical” system the DBA has to troubleshoot at 2:00 A.M.

So in case you’re a developer, and in case you think DBA’s “just do admin” – think again. DBA’s spend their whole day in this world, and can be a valuable asset to your development efforts. Bring them in early, bring them in often, and whatever you do – don’t design alone. Business Analysts, Developers and Data Professionals are needed to make a good, sustainable, secure, well-performing database.

Published Monday, November 30, 2009 9:37 AM by BuckWoody



Adam Machanic said:

Okay, so there are many different kinds of "data professionals". And smarter companies have started giving these people different titles depending on job function. So you have your DBAs--production support people, generally. You have your database developers or engineers doing development. And then there are data integration people, data analysts, BI people... Why give everyone the same title?

November 30, 2009 12:54 PM

Adam Machanic said:

And I almost forgot about data architects. And database architects. Different roles and different titles, depending on the complexity of the project and the size of the team...

November 30, 2009 1:00 PM

Jen McCown said:

"Bring [DBAs] in early, bring them in often, and whatever you do – don’t design alone. Business Analysts, Developers and Data Professionals are needed to make a good, sustainable, secure, well-performing database."

Preach it, brother!  I can't agree enough, and I hope this message really starts getting out there.  

November 30, 2009 1:12 PM

Bob Probst said:

The DBA in our office only deals with the hardware and SQL software/security/backups/io.  That's it.  No design work, no tuning, nothing else.

I like it that way (and he's an invaluable teammate) but that's why some people have that impression.

November 30, 2009 2:50 PM

andyleonard said:

Excellent post Buck!

  Reminded me of an oldie but goodie:

:{> Andy

November 30, 2009 4:22 PM

syi916 said:

If your "DBA" only does hardware / administrative duties, the data modeler / designer should also be some flavor of a "DBA"  The term "DBA" is perhaps misleading.

I've seen countless systems that ballooned out of business needs (developed by app dev or business analyst) without consulting any knowledgeable "dba"s that required months (if not years) of rearchitecting. Don't get burned... knock on your dba's door often!

November 30, 2009 5:29 PM

Alex K said:

Yep, read quite a few similar posts and articles before. Let me be the Devil's advocate here.

Quoting from Donald Knuth, "premature optimization is the root of all evil."

Seriously, when I am starting a project, I might not know if the project will get traction or not, I might not know whether I need a secure and performant database at all. Right now I am rolling out a new subsystem, and all my shorter strings go to VARCHAR(50) columns, and longer ones go to VARCHAR(200), and under the circumstances this is the right thing to do - at this early stage it is more profitable not to research proper column lengths. I am not bringing in any help, and I am not using my own database design skills either.

If needed, I will refactor later, and refactoring with modern tools is much easier than what it used to be.

Starting a new project is very different from running a well established one.

November 30, 2009 10:05 PM

RichB said:

While premature optimisation may be the root of all evil, it does rather assume that what has been created hasn't been brought to life by a complete ignoramus...

The application of a certain level of knowledgable design and best practice - you know stuff like using sensible datatypes, structures and oooh, stuff like primary keys and clustered indexes should be assumed as having taken place before you consider 'optimisation'.

Probably be easier just to let the developers do their stuff with an identity and a text field with a bit of xml in it, right?

December 4, 2009 10:21 AM
New Comments to this post are disabled

About BuckWoody

This Blog


Privacy Statement