Programadores experientes devem conhecer as consultas ao banco de dados? [fechadas]

Existem muitos programadores por aí que também são especialistas em redação de consultas e design de banco de dados.

Este deve ser um requisito essencial para ser um programador especialista ou engenheiro de software?

Embora existam muitas semelhanças na maneira como as consultas e os códigos são desenvolvidos, minha opinião pessoal é: as consultas parecem ter uma estrutura diferente do código e pode ser difícil dominar as duas simultaneamente devido às diferentes abordagens.

Se a gravação da consulta ao banco de dados deve ou não ser um requisito principal, depende do trabalho, mas os bancos de dados relacionais são onipresentes na tecnologia atual.

Portanto, se eu conhecesse um programador que não sabia escrever consultas de banco de dados, esperaria uma de duas coisas:

1. Eles geralmente são inexperientes.
2. Eles são altamente especializados em outro campo (por exemplo, sistemas embarcados) e nunca precisaram aprender.

As consultas ao banco de dados são fundamentalmente diferentes das linguagens de programação mais padrão. Eles são algébricos e destinam-se a operar com dados relacionais, enquanto C # ou Java são imperativos e operam em discos, memória, entrada do usuário, etc.

EDIT: Como foi apontado nos comentários por mim e por outros, existem algumas razões válidas pelas quais um desenvolvedor experiente pode não conhecer bem as consultas ao banco de dados:

• A equipe deles usou ORM / NoSQL
• Sua equipe tinha programadores de banco de dados
• A complexidade do aplicativo estava na lógica de negócios e as consultas ao banco de dados eram triviais
• Sua equipe distribuiu o trabalho de forma que alguns programadores não escrevessem consultas

Embora válidas, essas advertências não são razões convincentes pelas quais um desenvolvedor experiente não saberia consultas de banco de dados. A menos que seja altamente especializado, um programador deve estar familiarizado com bancos de dados relacionais.

Em resumo, os desenvolvedores mais experientes devem conhecer as consultas ao banco de dados .

Qualquer engenheiro de software deve ter um entendimento básico de bancos de dados e como armazenar e recuperar dados usando SQL, pelo menos até o nível em que eles tenham um entendimento do que isso pode ser usado (e com isso eu incluiria um entendimento de chaves, visualizações). , procedimentos armazenados e gatilhos).

Nem todo engenheiro de software precisa ser um especialista, e o nível de conhecimento necessário realmente depende do tipo de software em que se concentra. Software incorporado, drivers de hardware e sistemas operacionais raramente usam SQL, mas o software de aplicativo (seja na Web ou na área de trabalho ou baseado em serviço / daemon) usa bancos de dados o tempo todo.

Existem algumas áreas de especialização (sistemas embarcados, por exemplo) em que o conhecimento do banco de dados não é necessário. Porém, a maioria dos aplicativos de negócios usa algum tipo de banco de dados e, se você não entender completamente como usá-lo corretamente, poderá criar uma bagunça no desempenho que é extremamente difícil de corrigir. A refatoração de bancos de dados pode ser um processo complexo e difícil, e muitos locais optam por não corrigir os problemas estruturais por causa dessa dificuldade e apenas se aprofundam em um buraco. Se você tem conhecimento de banco de dados, o design é muito mais fácil e muito mais provável que funcione bem ao longo do tempo.

ORMs não substituem o conhecimento do banco de dados. Qualquer pessoa que use um sem conhecer os conceitos básicos de consulta e design de banco de dados está fadada a ter um banco de dados com desempenho ruim e mal projetado que afetará a capacidade de longo prazo do seu aplicativo para lidar com a carga. ORMs nas mãos de alguém que sabe o que está fazendo estão bem; nas mãos de pessoas que não podem se incomodar em aprender sobre bancos de dados, elas geralmente são um desastre.

Se eu tivesse um projeto com um back-end de banco de dados, o especialista em banco de dados seria o segundo desenvolvedor que eu contrataria (depois do desenvolvedor inicial do aplicativo). Os bancos de dados geralmente não são descartáveis, pois os dados ainda estarão lá quase da mesma forma 20 anos depois, vale a pena ter experiência nos estágios iniciais.

Os projetos costumam ter problemas porque não contratam essas pessoas até que o banco de dados possua 100.000.000 registros e esteja em execução lenta. Ou eles culpam a ferramenta por ser ruim (o SQL Server não é lento se você projetar corretamente) e não por sua incompetência de design.

A resposta politicamente correta: depende. O conhecimento de SQL não tem valor algum, se o desenvolvedor nunca trabalha com bancos de dados relacionais (e nos dias de hoje dos aplicativos NoSQL, isso é bastante provável).

Segundo, quando há um DBA ou um gravador de consultas em tempo integral (qualquer que seja o título), o entendimento também é de menor importância.

Só é realmente importante se o desenvolvedor precisar ser um especialista em tudo e se houver um requisito em seus projetos para usar um banco de dados relacional (por exemplo, em aplicativos Web antiquados ou se conectar a bancos de dados existentes)

Minha opinião pessoal: Não. Um desenvolvedor de software experiente deve ser capaz de aprender uma nova habilidade (como SQL) se e quando necessário, não "por padrão". A flexibilidade e a capacidade de aprender e entender é, o que diferencia um bom desenvolvedor de um bom. A regra do 'martelo de ouro' também se aplica - se você tiver um desenvolvedor com amplo conhecimento de SQL, é muito provável que ele desenvolva a ferramenta que ele conhece melhor - bancos de dados relacionais - para tentar resolver todos os problemas, embora isso não ocorra necessariamente. para ser a melhor solução. Obviamente, isso também se aplica aos advogados do NoSQL;;).

Escolher a ferramenta certa para o trabalho certo é o que um programador experiente deve saber.

Confira esta introdução da wikipedia à Programação para computadores:

A programação de computadores (geralmente abreviada para programação ou codificação) é o processo de projetar, escrever, testar, depurar / solucionar problemas e manter o código fonte dos programas de computador. Este código fonte está escrito em uma linguagem de programação. O objetivo da programação é criar um programa que exiba um determinado comportamento desejado.

As consultas ao banco de dados têm seus próprios idiomas; elas podem ser projetadas, testadas, depuradas e mantidas. O objetivo de uma consulta ao banco de dados é permitir que você obtenha as informações necessárias, da maneira que você precisa.

Então eu acho que é programação, definitivamente.

Um bom engenheiro de software com experiência em aplicativos corporativos e de negócios (EDIT: especificamente em projetos que utilizam um RDBMS) deve ter conhecimento especializado em escrever consultas de bancos de dados relacionais no formato padrão. Além disso, eles devem ser capazes de entender esquemas complexos e propor projetos de esquemas de complexidade pelo menos moderada.

O design do esquema extremamente avançado ou complicado deve ser o domínio de um modelador de dados ou arquiteto funcional.

Isso não significa que os programadores de banco de dados também não tenham um local. Procedimentos armazenados complexos, consultas complexas e eficientes e design e arquitetura de software da camada de banco de dados focados nas ferramentas e ofertas exclusivas de um único fornecedor de banco de dados (por exemplo, Oracle, MySQL, SQLServer, etc ...) devem ser deixados quando possível para software profissional engenheiros com experiência com essas ofertas altamente especializadas e complicadas.

A grande maioria dos sistemas comerciais e empresariais, no entanto, na minha opinião, não justifica a necessidade de modeladores de dados e programadores de banco de dados especializados, mas eu já trabalhei nesses projetos antes que GRATUITAMENTE se beneficiassem do conhecimento e da experiência que essas pessoas trouxeram para a mesa.

Outros já responderam sua pergunta sobre consultas ao banco de dados.

O design do banco de dados é um tipo específico de design. Não é tão difícil de aprender, mas o designer de banco de dados típico não tem tantas oportunidades para criar um banco de dados.

O local em que estou trabalhando agora tem o mesmo design de banco de dados que tinha em 1970. Movemos o banco de dados de IDMS para DB2, mas é o mesmo design de banco de dados de rede. Eu tive a oportunidade de criar 5 novas tabelas do DB2 nos 9 anos em que trabalhei aqui.

Eu suspeito que existem muito poucos locais de trabalho com um designer de banco de dados dedicado. Portanto, concluo que o design do banco de dados é considerado parte do repertório de um analista sênior.

Estou francamente surpreso que muitos de nós pensem que todo desenvolvimento gira em torno de um banco de dados e de um banco de dados SQL.

Outros mencionaram as várias maneiras pelas quais podemos evitar o âmago da questão do SQL em nossos trabalhos, mesmo quando trabalhamos (indiretamente) com bancos de dados, mas e quanto a todos os desenvolvedores que escrevem o firmware para os 101 produtos elétricos, cada um de nós possui? E os caras especializados em monitoramento em tempo real?

Eu sugeriria que a maioria dos desenvolvedores de hoje terá habilidades de SQL em graus variados, mas está longe de ser um barômetro de sua capacidade.

Eu acho que você superestima a importância dos bancos de dados em software.

Muitas classes de aplicativos não são centradas no banco de dados.

Precisamos de um DBMS em processadores de texto e editores de imagens agora? E quanto aos sistemas de reconhecimento de voz e visão computacional, eles contêm muitas consultas ao banco de dados?

E o que dizer dos editores lineares de vídeo e dos mecanismos físicos de videogame?

Eu esperaria que um desenvolvedor generalista tivesse pelo menos conhecimento das tecnologias de banco de dados (relacionais ou não) e seria capaz de discutir os prós e os contras de usá-las. Caso contrário, eu ficaria com medo de que tudo o que eles sabem fazer é colocar dados em arquivos simples.

Não acho que a escrita de consultas deva ser um requisito essencial para os programadores. Dito isto, acredito que um programador que pode escrever consultas e criar bancos de dados seria mais valioso para uma organização.

No entanto, se esse programador puder escrever apenas consultas do tipo "selecione * de tblxxxx", eu não consideraria esse programador um especialista. Da mesma forma, se o banco de dados criado por esse programador colocar relacionamentos um-para-muitos em uma tabela em vez de duas, então eu não consideraria esse programador um especialista.

Eis como explico isso para pessoas que não são de TI. Os profissionais de TI se especializam em determinadas áreas, da mesma forma que os carpinteiros, eletricistas e encanadores se especializam em campos respeitados. Eles tendem a se sobrepor a algumas das habilidades, mas não são especialistas em todas as áreas. Um eletricista pode executar tarefas simples de carpintaria com confiança, mas não seria um bom presságio tentar lidar com estruturas complexas.

Da mesma forma, um programador pode e deve saber como escrever ou manipular consultas simples e designs de banco de dados, mas não se espera que ele crie uma estrutura de dados complexa.

Olhando em nosso departamento, depende:

• Nossos desenvolvedores de desktop / web / servidor . É necessário pelo menos escrever instruções básicas a avançadas, dependendo de sua especialidade. Para otimização, temos alguns administradores de banco de dados especializados.
• Nossos programadores incorporados . Muitos nunca passaram do "select * from mytable". No entanto, isso também mudou nos últimos meses com a introdução do sqllite em seus projetos.