7

For some reason I got thinking the other day about DBAs and what they do. This thread goes some way to answer this question, but then I looked up the leading jobs site in my area out of curiosity, and it seems like there are more Oracle DBA jobs around than many other technology specialties. Even relatively common-sounding ones, such as "Java Developer" or "Network Administrator".

Here's the thing: I've been in this industry for ten years, worked in several jobs (a couple in fairly large corporate shops too), and I've never actually seen a real live DBA. There was usually a self-taught "database guru" around who was the goto guy for database issues (otherwise employed as a developer like the rest of us), but I've never seen anyone in an official DBA role, anywhere, ever.

So, where are all the DBAs? I'm guessing that since all the places I've worked so far were relatively application-oriented, I've just never experienced a very hardcore DB-heavy environment. At the same time, at least one of the jobs I've had seemed like a pretty extreme data-centred operation (real time market/trading systems, huge databases), and even here the only "database people" were these "developers who were database gurus on the side". No official DBA roles.

Is it really just a case of me never having been in the kind of environment where DBAs are needed? If so, what kind of environment is that? Is this phenomenon perhaps to do with data centres being separate/outsourced operations these days, so most application level programmers just don't see them anymore?

Note: I am basically trying to understand where the separation between "developers who know databases well" and actual DBAs is. It seems like a lot of dev roles require some pretty hardcore database knowledge these days (and that most development teams - even in quite DB-heavy environments - get by without an official DBA on staff). ie Please don't close or move to dba.SE.

|improve this question
  • 1
    Perhaps you'll get a better answer at dba.stackexchange – yannis May 31 '11 at 0:32
  • 2
    +1 - Really, where are they hiding? Especially when you need them :-) – Martin Ba May 31 '11 at 7:26
5

A DBA is not a SQL developer. A DBA is an administrator. He/She installs, configures, backs-up, restores, grant privilges, control security, does physical tuning, migration, manage vendor app DBs (SAS, PeopleSoft) etc of a database. All medium-large enterprise (banks, insurance, retail etc) with valuable data in DB will have a DBA whether in-house or outsourced. And no a developer is not suitable for a DBA; the roles, responsibility and even work hours can be different.

A database Developer is an SQL expert who is a part of the application development team. It is he/she who develops the logical data model (tables, views, indexes etc) and all SQL code (Stored Procs, dynamic SQL) including optimisation. This person may be an exclusive SQL developer (as I have in my team) or a shared SQl/OtherPorgrammingLanguage developer. Most importantly this person would have no access to production DBs and all changes would actually be performed by the DBA using change scripts or other tools. The DBA in turn should NOT question the SP code or Table schema as that is owned by the application ( I am talking about apps that own the DB and all data goes into the DB via the app).

|improve this answer
  • 2
    You say the DBA shouldn't question the SPs or schemas, but shouldn't they look at any scripts that get requested to run into Production? – Jon May 31 '11 at 0:49
  • 2
    I'm not sure that DBA needs to be silent on SP code or table schemas, since if there is a problem with it in production, he is likely to get called. – JohnMcG May 31 '11 at 1:32
  • @JohnMcG - In a proper release management, code (including SP) will go through system testing, performance testing (if required) and pre-production deployment testing. So there is little risk and in any case if they get called and find it as a sql problem then the dev or support team should be called in turn. Moreover in many apps with dynamic inlined SQL or ORM DBAs have no scope to oversee this anyway. – softveda May 31 '11 at 3:28
  • If I'm the person who controls security on something, I will not let anything get deployed without it going through me first. That includes code and SQL changes. It's just too easy for someone to make a decision like "Let's just add a user as part of the update script". I agree not for things like questioning performance etc. though. – Martin Apr 19 '13 at 16:20
  • This answer is fine, but one should mention that there is also the DevOps approach which tries to keep those different roles not so strict apart from each other. – Doc Brown Nov 7 '17 at 8:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.