THE SQL Server Blog Spot on the Web

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

Andy Leonard

Andy Leonard is CSO of Linchpin People and SQLPeople, an SSIS Trainer, Consultant, and developer; a Business Intelligence Markup Language (Biml) developer; SQL Server database and data warehouse developer, community mentor, engineer, and farmer. He is a co-author of SQL Server 2012 Integration Services Design Patterns. His background includes web application architecture and development, VB, and ASP. Andy loves the SQL Server Community!
Note: Comments are moderated. Spam shall not pass! </GandalfVoice>

Database Professionals: An Enterprise Requirement

A friend (who shall remain nameless) recently told me his company interviewed a competent database developer and DBA. All seemed in agreement an offer would be forthcoming until the very end of the recruiting process. At that time, someone made the comment "we don't need a DBA."

It would be notable if this sentiment wasn't so widespread - but I see it often. How often? Well, I would have to tell you how I see it to qualify that statement:

You see, people rarely say to me "We don't need a DBA." Mostly I see it in their applications - many of them prominent companies in which you may even own stock. I can tell when I examine their schema. I can see it when I execute Profiler against their SQL Server database.

Now, there are lots of reasons to design a denormalized schema. And there are lots of reasons to encapsulate the business rules in code. This is not what I'm talking about - though some of these systems would clearly perform better (or at all, in extreme cases) if they took advantage of better design patterns.

I'm talking about designs where this much is obvious:

1. At least two people designed the data layer; and
2. They did not communicate during the process.

Often, enterprise-level database design is shoveled onto developers as a secondary task. No, I'm not making this up - it's too tragic to joke about. There are developers who can handle this task. But there are more who believe they are database developers than actually are. (Before I became a SQL Server DBA I was a developer who thought I was a SQL Server DBA...)

There will doubtless be readers who can provide examples of how their enterprise application was built by junior developers who did the database and code work and whose systems are performing just fine. I'm happy for you and sincerely hope the system scales. 

Designing a scalable solution  - database, application, or enterprise architecture - is one of those things that consumes time, thinking, resources, and money during the early phases of an enterprise development cycle. But it is - hands down - one of the best investments (if not the best) in the solution.

In today's market, scalability is as optional as security. And like security, a scalable design is not something you "add later." It's not part of the foundation - it is the foundation.

My experiences with designing scalable solutions has proven there is no free lunch nor any shortcuts that work. If anyone - me included - skips the work of designing for scalability, there comes a day when they (or I) must pay the fiddler. From what I hear and have experienced, designing in this fashion is most often sacrificed on the altar of the deadline. Trust me, if it falls apart in six weeks or six months, you haven't saved any time - and you may have lost a job or a customer.

Someone told me this and I remember because it has proven true several times over: "Deliver quality late, no one remembers. Deliver junk on time, no one forgets."

If you're building (or upgrading to) cutting edge technology, you need a DBA.

:{> Andy

Technorati Tags: Software Business scalable database design quality

Published Thursday, July 12, 2007 10:53 PM by andyleonard

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS

Comments

 

WesleyB said:

Amen!

I thought this problem only existed in Belgium.

July 13, 2007 6:19 AM
 

Adam Machanic said:

If everyone hired competent DBAs, we (consultants) would be out of the job ;-)

July 13, 2007 8:36 AM
 

Denis Gobo said:

>>If everyone hired competent DBAs, we (consultants) would be out of the job ;-)

In that case you would be working as a full time employee instead of a consultant  ;-)

July 13, 2007 9:09 AM
 

Adam Machanic said:

Wouldn't that mean that I'd have to be a competent DBA?

July 13, 2007 9:19 AM
 

Denis Gobo said:

>>Wouldn't that mean that I'd have to be a competent DBA?

You probably need to be a hybrid DBA

A DBA/DB Developer will become the Prius of computer programmers

you need to know:

Administration

DB Design

T-SQL

SSIS

SSAS

SSRS

SQLCLR

.....

...

..

Yes you are more expensive than just a DBA or just a developer but the company will getter mileage out of you, just like comparing a prius with a VW Jetta (Bora for those in Europe). A Prius is more expensive but gets better mileage (Jetta TDI doesn't count)

Denis

July 13, 2007 9:32 AM
 

Adam Machanic said:

I want to be the Humvee of computer programmers... Burn lots and lots of fuel, but can take a few bullets, ride over rough terrain, and go where others can't, when necessary <g>

July 13, 2007 9:47 AM
 

Denis Gobo said:

Are you saying you want to be Agile?

July 13, 2007 9:49 AM
 

Adam Machanic said:

Hmm, is a Humvee really agile?  Agile sounds to me like one of those water/land vehicles :)

July 13, 2007 10:48 AM
 

Andy Leonard said:

Eric Wise drew some heat from the developer community at CodeBetter.com with this post about the need

July 13, 2007 9:14 PM
 

Chris Harmon said:

I agree with the need for a hybrid, but I'm from the software programming side and would so classify it as a hybrid programmer, with solid programming skills AND DB development skills (but including tuning/troubleshooting/maybe SSIS). Where I have in the past grumbled is when I have to venture far into what I consider "DBA territory"... which brings me to a recent story:

A few months back I was looking for a new job, and interviewed for one looking for a ".NET/SQL Server Programmer". Interviewing went well, but it was obvious to the interviewers that my skills were more heavy on the development side (but solid for .NET as well as SQL Server), but it turns out they were looking for someone with very thorough DBA skills! If it wasn't clear, I didn't get the offer but about a month later, I saw in a posting to the local Richmond SQL Server UG a guy they did end up hiring looking for anyone to provide guidance on getting .NET experience, because he had none but really needed it :)

Where I now work at, it kind of is a mix with only a few programmers and a DBA. We all work together including the database side of development... we are kind-of all becoming hybrids together I guess.

July 16, 2007 7:55 AM
 

James Luetkehoelter said:

Personally I'd like to see the titles "database developer", "DBA", "Production DBA", etc., go away entirely. I like just "database professional" that specializes in certain areas. There are just way too many things that "hook" into a database to isolate that knowledge into a single job role. I'd love to see us all understand a portion of what the other does, a sort of cascading overlap in job descriptions/responsibilities.

Unfortunately, I think it unlikely to change any time soon. Sigh...

July 16, 2007 11:41 AM
 

Adam Machanic said:

Today I gave two talks at New England Code Camp 8 . A fun experience as always, and for those of you

September 29, 2007 4:08 PM
 

Peter W. DeBetta said:

K. Brian Kelley - Andy blogs at SQLblog.com (not SQLblogS.com - a defunct site)

February 22, 2008 4:57 PM

Leave a Comment

(required) 
(required) 
Submit

This Blog

Syndication

My Company


Other Blog

Check out my personal blog...
http://andyleonard.me

Contact Me

Twitter: @AndyLeonard
Email: andy.leonard@gmail.com

Powered by Community Server (Commercial Edition), by Telligent Systems
  Privacy Statement