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>

Who Thinks Like Database Professionals?

Introduction

I was talking to my team this morning and we were wondering about some design decisions. One of the things that came out of the discussion was: Database professionals think differently.

Differently? How?

A little story: Before I was a database person I did web development. That's a little misleading because I wrote very little that made it onto the big web. Most of my work ran on enterprise intranets.

Back then, I started using Access first (and I admit it). After I crashed Access one weekend, I learned about SQL Server 6.5 and started working with it. After a year or so I started playing with SQL Server 7.0. About six months later I considered myself a DBA.

Were You a DBA?

No.

But You Considered Yourself a DBA?

Yes.

When Did You Learn You Weren't a DBA?

I learned I was not a DBA when I started working on my first Very Large Database (VLDB) project. I started doing database work and realized how little I actually knew. The gaps in my knowledge were readily identifiable, but that was nothing compared to my thinking. I didn't think like a database person. 

I'm not going to mislead you: Sometimes, the ability to think differently than a database person adds value. But right then, it was a major liability.

Thinking about parallelism and thinking in sets is different. It's way different from the way I thought about web development. I don't think I'm alone in any of my experiences. I think lots of people have trouble thinking in sets, about parallelism; and quite a few developers think they're DBAs.

It's important to note that there are some developers who are DBAs. I believe they represent a subset of all the developers who think they are. Maybe I'm just biased because of my experience, I'm not sure.

One Last Thing

The most important thing I learned working with that VLDB: I was not a DBA when I started, and I really wasn't a DBA when I finished. I knew a lot more about SQL Server database administration, but that doesn't make a DBA - in my opinion. I learned I'm a database developer, which is a different animal from an application developer and from a DBA.

I can hear you thinking: "What makes a DBA, Andy?" I'm glad you asked. I don't think there's a formula, really. I know some really good DBAs (a couple of them are also really good developers), and they share some traits. One thing they all have in common is they're detail-oriented.

Conclusion

What do you think? What are the differences between the thinking of database professionals and other technology professionals?

:{> Andy

Published Tuesday, March 31, 2009 10:30 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

 

SQLBatman said:

Nice post Andy, and congrats Grandpa!

It is a fine line. At what point do you become a DBA? And in different shops the function of a DBA is a different role, making it even more complicated to define.

For me I draw the line at the moment you no longer think about your needs, but the needs of everyone using the system. Once you start to realize that the changes you make can affect others, that is when you have crossed the line into the DBA dominion.

March 31, 2009 10:04 PM
 

Morris Lewis said:

Having been both a programmer for 30 years, a database developer for 25, and a DBA for about 10 years, I can say you are completely correct about each kind of role approaching designs differently. My current role is a production DBA, and I lean towards the Vulcan philosophy that the needs of the many outweigh the needs of the one. I don't steadfastly refuse to give developers sysadmin rights on the production server because I'm an autocrat. I refuse them because there are over a thousand users depending on the server to stay functional. The programmer can just learn how to write code that doesn't need god-like powers to run. I know from experience doing what they do that it can be done, it isn't hard, and it actually makes you write better code. Now, if I could just get the programmers of the world to realize that 99.99% uptime still means the server is down for a little less than 3 hours a year. Unfortunately, robust, graceful response to server failure just isn't high on the list of design goals for developers. Come to think of it, that right there is a big difference between programmers and DBA's.

March 31, 2009 10:30 PM
 

Jose Guia said:

March 31, 2009 11:53 PM
 

GrumpyOldDBA said:

I don't think it's as simple as you may think. As a DBA I've no idea what makes me a DBA ( I'd say I was a production DBA ) When I first encountered RDBMS ( it wasn't sql server ) I was part of a development team, it just seemed I understood it all quicker and  better than the others so in fairly quick time I became "the DBA", things were probably more simple then, SQL 2008 is a massive subject area compared to SQL 6.0. I enjoy what I do 100%+ and I think perhaps you need to be very passionate about what you do ( I'm told I'm very passionate about my role ). I don't think you can be a DBA unless you really enjoy it - or you need to help cure insomniacs by describing what you do for a living!

April 2, 2009 11:18 AM
 

Matthew Vines said:

I'm not a DBA, but if it is anything like being a developer I would say you become one once you can identify what you don't know about your trade.  

I'm still relatively young in the development world, at only 4 years of real work experience, but I can say I have only REALLY been a developer for the past two years or so.  And what made me a developer was that I finally had enough of a grasp on the concepts of software development that I could look at the vast array of skills that it requires, and identify the items that I lacked.  Which then allowed me to start filling in the holes and identifying new places to improve.  

Before that day I just solved the problem in front of me, oblivious to the overall dynamic of what it really took to do my job successfully.  

Again, I'm not a DBA, just a guy who solves whatever SQL problem happens to be in front of me.  But I would venture a guess that it probably works in much the same way.

April 2, 2009 6:21 PM
 

rudyx said:

The major difference between thinking and being is the ability to see the forrest for what it is and all you do not know about it  instead of just a few trees that you think you know everything about !

April 4, 2009 11:29 PM
 

Thex said:

Does it matter if you think you are a DBA or not? Just think about getting things working and working well, the line of business(s) that uses the data and can they access it when they need it, what can I (you) do the make it better, faster, strong, etc.

Yes my title is DBA is that really a good tile? But every DBA does things differently depending on the company your are working for. I do administration, analysis, custom reports with SSRS and network analysis too. So do this make me an official DBA? I don't know or care. But I do care about doing a good job, being helpful to other and look at ways to make things better.

It funny the more I learn about being a DBA the more I realize that I don't know enough.

Just my 2 cents worth.

April 6, 2009 10:54 AM
 

Steve D said:

I always thought the disctinction was who had the performance problem shoved upon them :)

April 6, 2009 2:18 PM
 

Robert Young said:

>> I learned I'm a database developer, which is a different animal from an application developer and from a DBA.

DBA tends to be defined as anyone who does the backups and restores.  For anything web (intra or inter)net, the KiddieKoders, aka application developers, in java or php or... think like the COBOL programmers of the 1970's:  all the data be mine, even if it's just a lump of clay.  Being a database developer, if only in one's mind, means worrying about the data structure in all that means.  

The problem is that hiring authorities overwhelmingly only know application developer (coder) and DBA (backup, restore, grants).  So, relational databases still end up being VSAM images (whatever the platform); such a waste of money on databases.

April 9, 2009 9:19 AM
 

John C. said:

If you do not know how to backup and recover a database to a point in time (roll forward) from an external (i.e. tape) backup while the entire company is down, without the assistance of vendor support then you are not a DBA. This is the #1 prerequisite before anyone can really consider them self a DBA if you can't recover to a point in time under pressure while the CEO, President, or CIO is standing in front of you tapping their glossy shoe on the floor then please don't call yourself a DBA. Use database developer, application developer, computer operator, perhaps Jr. DBA or DBA in training, etc.

The best DBAs are;

- programmers and can write code in at least one language and can explain set theory to other IT folks who grew up thinking top-down, loops, or use temp tables constantly

- do not typically use a mouse to administrate a database, instead they know how to write elegant programs in operating system scripting languages which are given many repeat runs in a development environment before ever being run in production

- meticulous in nature, non-risk takers, and aware if they have a bad day the entire company can have a bad day...real DBAs know you don't get a second chance to press the Enter key on a Truncate Table or Drop statement

- understand what "third normal form" is on a relational database and why it's good for OLTP but not so good for a Data Warehouse

- can perform database design and explain to others what primary keys are, not null constraints, unique indexes, etc.

- able to decipher and tune the worst written SQL code

- fluent with all index types are and the purpose of each (b-tree, hash, cluster, etc.)

- able to create query plans, analyze them, and find table scans and other query performance problems

- fluent in the Operating System the database runs on; concepts like processes, sub-processes, threads, virtual & physical memory, and all manner of storage related jargon (SAN, NAS, HBA, Fiber) etc.

- lovers of server, storage, and network hardware and always wants to know more about it and how it will affect the database

- big geeks that have never found a server with too much RAM, and operating system with too many bits, or a storage system with too little latency

- one of the most misunderstood of all the IT disciplines, but sit in the center of the action between application and the hardware

- not trained in a day or in most colleges, they learn through many years of hands on experience, mentoring, specialized training, and conferences, and a whole lot of reading of technical books and manuals

April 6, 2013 10:34 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