Até que ponto um administrador de banco de dados precisa conhecer as linguagens de programação em nível de sistema ou aplicativo (por exemplo, .NET ou PHP) além de "apenas SQL"?
Para os fins desta pergunta, nenhuma versão específica do padrão SQL é considerada para esta resposta (SQL ANSI 86, SQL ISO 87, SQL: 2008), pois a pergunta é relativa a idiomas de desktop ou servidor fora do domínio do SQL.
Respostas:
Depende.
Em uma grande loja, talvez não porque você tenha milhares de servidores para cuidar e suas ferramentas sejam fornecidas. Em uma pequena loja, você provavelmente precisará de mais conhecimento, porque possui uma missão mais ampla.
As linguagens de script (PowerShell, cmd.exe por exemplo) são sempre úteis para monitorar, implantar etc. Muitas vezes eu tive alguns scripts Perl que precisei manter (quase). Depois, existem os diversos pacotes ETL que você deveria saber.
Dizendo isso, a maioria dos DBAs (que eu conheço) seria capaz de escrever coisas básicas sobre CLR ou conhecer bem o PL / SQL. Para mim, a linha divisória é conhecer os padrões mais amplos ou a arquitetura do .net ou Java. Não preciso dele como desenvolvedor de banco de dados ou DBA. Da mesma maneira que .net ou PHP ou Java Monkeys não entendem o design, a arquitetura ou o código do banco de dados, assim como eu.
Pessoalmente, decidi parar de procurar o idioma mais recente ou melhor do cliente anos atrás e focar no trabalho de banco de dados. Isso não me torna um "não programador": eu precisaria aprender novamente se fosse necessário.
Conheço os DBAs que se safam com pouca ou nenhuma habilidade de programação, mas todos os DBAs que já considerei bons tinham pelo menos habilidades de programação razoáveis. Um ou dois em que eu consigo pensar possuíam antecedentes substanciais de desenvolvimento e eram bons desenvolvedores por direito próprio. Há uma quantidade razoável de ferramentas de código aberto escritas por pessoas que trabalham como DBAs em seu trabalho diário e no IIRC, o cara que escreveu o TOAD costumava trabalhar como DBA.
Dependendo da função, você pode estar escrevendo ou ajustando consultas, escrevendo scripts para automatizar tarefas ou consultando o design do aplicativo. Em alguns casos, você pode estar apenas cuidando de vários servidores através do OEM ou de alguma outra ferramenta de monitoramento.
Os ambientes modernos de desenvolvimento "corporativo", como .Net ou Java, são complexos o suficiente para que um desenvolvedor possa fazer carreira apenas por se especializar neles. Como um DBA, particularmente no espaço de desenvolvimento, ter um conhecimento prático de C # ou Java pode não prejudicar, mas você provavelmente não passará muito tempo codificando neles.
Você provavelmente obterá mais milhas de qualquer ferramenta de script usada em sua plataforma, embora muitos sistemas exponham .Net, Java, COM ou APIs de serviço da web. Se você precisar codificar algo nessas APIs, precisará de pelo menos um conhecimento básico de trabalho sobre algo que possa consumir essa API. No entanto, as habilidades avançadas de arquitetura de aplicativos geralmente não são necessárias para fazer isso.
Alguns desenvolvedores terão fortes habilidades de banco de dados, mas o medo irracional de bancos de dados é bastante comum nos círculos de desenvolvimento. Muitos desenvolvedores também nunca realmente se deparam com o paradigma de 'operações de conjunto' subjacente ao SQL. Como um DBA de desenvolvimento, você pode lidar com as conseqüências disso e talvez ter que intervir no código de procedimento armazenado para resolver problemas de desempenho.
O ETL e as ferramentas em torno do banco de dados também podem ser de responsabilidade do DBA. Eu já vi várias funções de DBA anunciadas que pareciam envolver uma quantidade significativa de trabalho de desenvolvimento de back-end. Isso será mais comum em empresas menores. Um pôster recente queria integrar métricas personalizadas ao Oracle Enterprise Manager, que possui uma API de plug-in para fazer isso. É bastante comum ver requisitos como esse aparecerem e, essencialmente, a única maneira de fazer isso é escrever algum código de cola.
Existem muitos "Funcionários de Ferramentas" trabalhando em TI e eles podem obter um trabalho útil, apesar do paroquialismo. No entanto, quando as ferramentas ficam sem vapor, geralmente a única maneira de fazer algo é realmente escrever um pouco de código para fazê-lo. É aqui que as habilidades de programação separam os homens dos meninos.
Eu diria que não normalmente, mas nunca dói. O SQL Server é grande o suficiente para que eu não ache que uma pessoa possa dominar todo o produto. Sou DBA desde o SQL Server 4.2 e me considero um especialista na maioria das áreas, mas admito que não seria capaz de escrever uma consulta MDX sem o google na ponta dos dedos a cada passo do caminho.
O que estou tentando dizer é que você não pode ser especialista em tudo. Ser um DBA realmente bom significa que você deve ser ótimo em T-SQL, mas provavelmente não é muito bom em .NET, ou pelo menos não é tão eficaz quanto outros que podem concentrar seu tempo no .NET.
É bom saber que o Powershell é o que entra e sai do SSIS. Fora isso, deixe as outras linguagens de desenvolvimento para os desenvolvedores.
Tem sido minha experiência que, embora a maioria dos DBAs tenha algum tipo de experiência em desenvolvimento, eles não precisam escrever código. Os DBAs realmente bons com os quais trabalhei tiveram amplo conhecimento de uma variedade de tópicos, incluindo scripts de shell, sistemas operacionais e conhecimento especializado em aplicativos (ex: PeopleSoft).
Eu tinha um instrutor de Administração de Banco de Dados na pós-graduação que nos deu uma lista de perguntas que qualquer bom DBA (Oracle) deveria ser capaz de responder: (vou postar alguns dos destaques da lista de aproximadamente 40)
Os DBAs (Oracle) precisam saber essas coisas para serem eficazes. A maioria dos desenvolvedores que conheço (que codificam contra Oracle) teria dificuldade em responder a um ou dois deles corretamente.
Se você é o DBA, provavelmente está trabalhando nas áreas de desempenho e segurança (entre outras). Isso pode envolver a criação de perfil e a assistência no ajuste de aplicativos clientes nos quais os desenvolvedores estão trabalhando. Portanto, certamente não faria mal saber o básico dos idiomas que os desenvolvedores estão usando e como fazer interface com o servidor de banco de dados. Para o SQL Server, isso provavelmente é .NET. Para o MySQL, provavelmente alguma combinação de php ou java.
Por exemplo, se o servidor for pressionado para encadeamentos de clientes, será útil informar aos desenvolvedores que eles devem usar instâncias singleton para seus ObjectDataSources para que possam reutilizar uma única conexão com o banco de dados. E também verifique se eles estão usando consultas parametrizadas corretamente para limitar a injeção de SQL. Coisas assim.
Você não fará nenhuma programação no sentido de desenvolver aplicativos clientes se for estritamente um DBA, mas deve saber como eles funcionam (em geral).
Bem, vamos ver, a Oracle usa PL / SQL, que é realmente semelhante ao Pascal (uma linguagem que costumava ser usada para produzir código de aplicativo de desktop, mas que caiu nos últimos anos, e os desenvolvedores mudaram para o Delphi, que alguns foram de lá para .NET) e o Oracle agora também suporta Java para algumas atividades. Como um DBA Oracle precisa conhecer todos os aspectos do sistema para ser bem apreciado, eu diria que conhecer Pascal e Java seria um requisito.
O TSQL tem capacidade para escrever código gerenciado .NET (CLR) para algumas das funcionalidades do Sql Server e, portanto, um bom DBA provavelmente precisará saber sobre isso (mas nem sempre pode ser usado em versões mais antigas, muito dos DBAs tendem a evitar esse conjunto de recursos na minha experiência).
Então esses são os dois grandes, e os que a maioria das pessoas se refere quando perguntam como você está perguntando. Não conheço todos os outros mecanismos para saber o que eles fazem e não suportam, mas sei que muitos outros têm integração de linguagem além do SQL.
Estou bastante convencido de que apenas grandes lojas com grandes aplicativos exigem um DBA que não seja de programação, pois pequenas lojas com bancos de dados simples podem se safar do desenvolvedor / DBA. Para que um DBA se torne o mestre de um produto (Oracle, SQL Server, qualquer que seja), é preciso haver demanda por esse conhecimento! O DBA deve estar sujeito a ambientes e problemas complexos para ajudá-lo a se tornar mais conhecedor. Isso é basicamente um discurso retórico meu, porque eu sou um DBA em uma pequena loja e não faço nada que exija mais de 2 neurônios, acho que estou perdendo meu tempo neste trabalho. Eu quero ser um desenvolvedor.