To what extent does a Database Administrator need to know system or application level programming languages (for example .NET or PHP) besides "just SQL"?
For the purposes of this question, no specific version of the SQL standard is considered for this answer (SQL ANSI 86, SQL ISO 87, SQL:2008) as the question is in regards to desktop or server languages outside the realm of SQL.
It depends.
In a big shop, maybe not because you have 1000s of servers to look after and your tools are provided. In a small shop, you'll probably need more knowledge because you have a wider remit.
Scripting languages (PowerShell, cmd.exe for example) are always useful though for monitoring, deploying etc. I've often had some Perl scripts I had to maintain (just about). Then there are the assorted ETL packages that you'd be expected to know about.
Saying that, most DBAs (that I know) would be able to write basic CLR stuff or know PL/SQL well. For me, the dividing line is knowing about the broader patterns or architecture of .net or Java. I don't need it as a DB developer or DBA. In the same way that .net or PHP or Java Monkeys don't understand database design or architecture or code as well as I do.
Personally, I decided to stop chasing the latest or best client language years ago and focus on database work. That doesn't make me a "non-programmer": I'd need to learn it again if I had to.
I've known DBAs to get away with little or no programming skill, but every DBA I've ever considered to be any good had reasonable programming skills at least. One or two I can think of had substantial development backgrounds and were fairly good developers in their own right. There's a fair amount of open-source tooling written by people who work as DBAs in their day job and IIRC the guy who wrote TOAD used to work as a DBA.
Depending on the role you might find yourself writing or tuning queries, writing scripts to automate tasks or consulting on application design. In some cases you may just be minding a bunch of servers through OEM or some other monitoring tool.
Modern 'enterprise' development environments such as .Net or Java are complex enough that a developer can make a career just out of specialising in them. As a DBA, particularly in the development space, having a working knowledge of C# or Java might not hurt, but you probably won't spend a lot of time actually coding in them.
You will probably get more mileage from whatever scripting tools are used on your platform, although a lot of systems expose .Net, Java, COM or web service APIs. If you need to code something against these APIs you will need at least a basic working knowledge of something that can consume that API. However, advanced application architecture skills are usually not necessary to do this.
Some developers will have strong database skills, but irrational fear of databases is quite common in development circles. Many developers also never really get their head around the 'set operations' paradigm that underlies SQL. As a Dev DBA you can find yourself dealing with the consequences of this, and maybe having to intervene in stored procedure code to sort out performance issues.
ETL and tooling surrounding the database may also fall into the remit of the DBA. I've seen quite a few DBA roles advertised that seemed to involve a significant amount of back-end development work. This will be most common in smaller companies. One recent poster wanted to integrate custom metrics into Oracle Enterprise Manager, which has a plugin API to do this. It is quite common to see requirements like this turn up, and essentially the only way to this is to write some glue code.
There are plenty of 'Tools Guys' working in I.T. and they can get useful work done in spite of the parochalism. However, when the tools run out of steam, often the only way to get something done is to actually write a bit of code to do it. This is where programming skills separate the men from the boys.
I would say not typically, but it never hurts. SQL Server is big enough that I don't think one person can master the entire product. I have been a DBA since SQL Server 4.2, and consider myself an expert in most areas, but I admit I wouldn't be able to write an MDX query without google at my fingertips every step of the way.
What I am trying to say is that you can't be an expert in everything. Being a really good DBA means you should be great at T-SQL, but are not likely very good at .NET, or at least not as effective as others who can focus their time on .NET.
Powershell is good to know, as is the ins-and-out of SSIS. Other than that, leave the other development languages to developers.
It's been my experience that while most DBA's have some kind of development background, they are not at all required to write code. The really good DBA's I've worked with have had extensive knowledge a variety of topics including shell scripting, operating systems, and specialized application knowledge (ex: PeopleSoft).
I had a Database Administration instructor in grad school who gave us a list of questions that any good (Oracle) DBA should be able to answer: (I'll just post some of the highlights from the list of 40 or so)
(Oracle) DBA's need to know these things to be effective. Most developers I know (who code against Oracle) would be hard-pressed to answer even one or two of these correctly.
If you're the DBA, you're probably working in the realms of performance and security (among others). This could involve profiling and assisting with tuning client applications that the developers are working on. Thus it certainly wouldn't hurt to know the basics of the languages the developers are using, and how to interface with the database server. For SQL Server, that's probably .NET. For MySQL, probably some combination of php or java.
For example, if the server is pressured for client threads, then it helps to be able to inform the developers that they should be using singleton instances for their ObjectDataSources so that they can reuse a single database connection. And also make sure they're using parameterized queries properly to limit SQL injection. Stuff like that.
You won't be doing any programming in the sense of developing client applications if you're strictly a DBA, but you should know how they work (generally speaking).
Well, let's see, Oracle uses PL/SQL which is really similar to Pascal (a language that used to be used to produce desktop app code but which has fallen off in more recent years, and developers have drifted to Delphi, which some have gone from there to .NET), and Oracle now also supports Java for some activities. Since an Oracle DBA has to know all aspects of the system to be well appreciated, I would say that knowing Pascal and Java would be a requirement.
TSQL has capacity to write .NET (CLR) managed code for some of the functionality in Sql Server, and therefore, a good DBA would probably need to know about this (but it's not always able to be used in older versions, so a lot of DBAs tend to shy away from that featureset in my experience).
So that's the big two, and the ones that most people refer to when they ask as you're asking. I don't know all the other engines to know what they do and don't support, but I know that a lot of other ones have language integration besides SQL as well.
I'm pretty convinced that only big shops with big applications have demand for a non-programming DBA, as small shops with simple databases can get away with the jack-of-all-trades developer / DBA. For a DBA to become a master of a product (Oracle, SQL Server, whatever) there has to be demand for this knowleadge! The DBA must be subjected to complex environments and problemas to help him become more knowleadgeable. This is basically a rant of mine, because I'm a DBA at a small shop and I don't do anything that requires more than 2 neurons, I think I'm wasting my time at this job. I want to be a developer.
