Better to be a "jack of all trades" or a "master of one" with SQL?

  • Or will the answer be, as one of the speakers at SQL in the City put it, "it depends?"

    Right now, I would class myself as more of a "jack of all trades, but master of none," when it comes to SQL. I'm not a great database designer (point-in-fact at my employer the devs do all of that,) I'm not a code-jockey, I'm not good with Reporting Services (we don't use it,) basically I know I don't know a lot about any one feature of SQL but I can hum along with the tune (and Google the stuff I'm not sure of.)

    I'm currently considering looking for a new job (there are things going on at my employer that have me concerned about the future of the company, and I'm too low on the food chain to even know if said concerns are justified or to make my concerns voiced,) and am just wondering what others here think.

    I would likely class myself more as a junior DBA level in some areas, maybe a bit higher in others, and lower in some.

    I think this may also have been asked at one point in one of the blog postings, maybe even Steves.

    Jason

  • Your first line is right. It does depend. There is no single right answer. However, in general, I don't think anyone sets out to be a top expert in certain aspect of SQL Server. They just end up that way. They work with SQL Server and work at getting better at what they work on. Over time, they find out they are especially good at or particularly enjoy a certain feature or group of features, and it grows into a specialty.

    For example, when database mirroring was first announced, I didn't set out to master it and eventually write a book on it. My work activities had me working with several different groups that wanted to be early adopters of it. There were a lot of bugs and issues int eh beginning, and very few solutions for dealing with them. It was other become really good with mirroring or not succeed at my job. I became really good out of necessity and through experience because I had to figure out the things that are common knowledge to many people today.


    My blog: SQL Soldier[/url]
    SQL Server Best Practices:
    SQL Server Best Practices
    Twitter: @SQLSoldier
    My book: Pro SQL Server 2008 Mirroring[/url]
    Microsoft Certified Master: SQL Server, Data Platform MVP
    Database Engineer at BlueMountain Capital Management[/url]

  • Thanks! That's pretty much what I figured the answer would be, but it never hurts to see what others think.

    Where I work, I very much need to be a "jack-of-all-trades" sort. Presumably at a larger employer it would be more typical to focus on one aspect with occasional forays into other areas...

    Jason

  • Every DBA interview I've ever had, what they actually wanted was "master of all trades", but what they'll settle for is "jack of all trades, master of the ones that really matter the most". Of course, what "matters the most" is subjective.

    Most employers seem to want at least familiarity with the common aspects of SQL Server. Very few will care if you're familiar with CLR integration, since (per MS) only about 3% of the installations of SQL Server even use that. Every single one of them will want to know that you can run a backup and restore a database from a backup. If they don't care about that, then it's even more important that you know it well, because they're probably not backing up their databases and don't realize that's a problem.

    So, know these areas at least enough to get by:

    Backup/Restore (point-in-time through the GUI is good enough, scripting is nice, but nobody will actually care HOW you do it, just that you can)

    Database corruption, at least how to detect it and some vague idea of what it is

    Performance tuning, minimally you should be able to tell what just brought the server to its knees so you can tell a dev what to fix, and some of the most common performance-killers (cursors, bad/missing indexing, views nested in views nested in views nested in views ..., pick your top 10 all time favorites)

    Normalization, even if you can't recite the levels, memorize "the key, the whole key, and nothing but the key, so help me Codd" and know what it means

    For extra points, know the differences between temp tables and table variables

    If you know at least those things, call yourself a Junior DBA, and you'll be honest. Know those well, and a few other areas reasonably well, and you'll be a Mid-level DBA. Common bits on that might be:

    Expand out knowledge on all of the above till you understand them, the pros and cons of options on them, and have some experience in each

    Know what traces and extended events are and have some familiarity with them, even if not mastery of them

    Replication/Mirroring/Log-shipping and other DR/BC concepts; minimally, know what a "co-location" is and what it's for

    Some level of server architecture: Clustering, virtualization, SAN vs local disks, how parallelism relates to CPU cores and threads, RAM options (AWE, 64-bit, etc.), and what an I/O channel is; Not mastery of this, just aweness of these things and some idea of what they mean in the world of databases

    More advanced performance tuning

    Senior level DBA is a subject of a lot of debate, but what it usually boils down to, for most employers, is the ability to do all the above things reasonably well, and the ability to educate others on them. Can you explain to a dev why his recursive UDF with nested cursors is a bad idea? Can you tell the IT server admins why SQL Server shouldn't run under Network Admin privileges AND be exposed through the firewall at the same time? Can you cleanly behead a dev who creates SQL Injection vectors in public-facing web pages without getting blood-splatter on your boss' suit? That kind of thing.

    Of course, there is one other version, which is "Mega-Authority DBA". This is the guy who can spout all the latest buzzwords, can obfuscate why the databases are both corrupt and have no backups so well that the managers give him a raise when the database goes down, and has everyone in the company running and hiding whenever he walks past because they're so intimidated that they don't care that all the databases perform like continental drift and are only accurate when measured by how many parsecs the data is off by.

    Pick which you want to aim for, and go for it.

    - Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
    Property of The Thread

    "Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon

  • Don't forget that even in a larger organization or larger team, that jack-of-all-trades mentality is still valuable. Even if you're the master of all things in one particular area there will still be times you will have to work with other team members. Either when problems arise or simply to implement something new. You may not be a storage expert, but you will definitely cross paths with the SAN Administrator at some point. It helps to be able to understand each other's areas so you can accomplish whatever task is at hand.

Viewing 5 posts - 1 through 4 (of 4 total)

You must be logged in to reply to this topic. Login to reply