Os programadores experientes devem saber as consultas ao banco de dados? [fechadas]

Se a escrita de consultas ao banco de dados deve ou não ser um requisito básico depende do trabalho, mas os bancos de dados relacionais são onipresentes na tecnologia atual.

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

1. Eles geralmente são inexperientes.
2. Eles são altamente especializados em outro campo (por exemplo, sistemas incorporados) e nunca precisaram aprendê-lo.

As consultas de banco de dados são fundamentalmente diferentes das linguagens de programação mais padronizadas. Eles são algébricos e planejam operar em dados relacionais, enquanto C # ou Java são imperativos e operam em discos, memória, entrada do usuário, etc. Mesmo linguagens funcionais como LISP ou Haskell que são mais algébricas em forma são menos orientadas para dados relacionais. / p>

EDITAR: Como foi apontado nos comentários de mim e de outros, existem algumas razões válidas para que um desenvolvedor experiente não conheça bem as consultas ao banco de dados:

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

Embora válidas, essas ressalvas não são razões convincentes pelas quais um desenvolvedor experiente não saberia as consultas do 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 conhecimento básico de bancos de dados e como armazenar e recuperar dados usando SQL, pelo menos até o nível em que eles têm uma compreensão do que isso pode ser usado (e com isso eu incluiria um entendimento de chaves, vistas, procedimentos armazenados e gatilhos).

Existem algumas áreas de especialização (sistemas incorporados, por exemplo) onde o conhecimento do banco de dados não é necessário. Mas a maioria dos aplicativos de negócios usa um banco de dados de algum tipo e, se você não entender completamente como usá-lo corretamente, poderá criar uma confusão de desempenho extremamente difícil de corrigir. A refatoração de bancos de dados pode ser um processo complexo e difícil e muitos lugares optam por não consertar os problemas estruturais por causa dessa dificuldade e simplesmente 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 com o tempo.

ORMs não são um substituto para obter conhecimento do banco de dados. Qualquer pessoa que use uma sem conhecer as noções básicas de consulta e design de banco de dados está fadada a ter um banco de dados de desempenho ruim e mal projetado que afetará a capacidade de longo alcance de seu aplicativo para lidar com a carga. ORMs nas mãos de alguém que sabe o que ele 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 (após o desenvolvedor do aplicativo inicial). Geralmente, os bancos de dados não são descartáveis, os dados ainda estarão lá na mesma forma, 20 anos depois, vale a pena ter experiência nos estágios iniciais.

Os projetos geralmente têm problemas porque não contratam essas pessoas até que o banco de dados tenha 100.000.000 de registros e esteja sendo executado lentamente. Ou eles culpam a ferramenta por ser ruim (nenhum SQL Server não é lento se você projetar corretamente) e não por sua incompetência de projeto.

A resposta politicamente correta: depende. O conhecimento de SQL não tem valor algum se o desenvolvedor nunca trabalhar com bancos de dados relacionais (e, atualmente, em aplicações NoSQL, isso é bastante provável).

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

Só é realmente importante se o desenvolvedor precisar ser um especialista em todos os negócios e houver um requisito em seus projetos para usar um banco de dados relacional (por exemplo, em aplicativos da web antigos ou conectando-se 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 precisar, e não 'por padrão'. A flexibilidade e a capacidade de aprender e entender é, sim, o que diferencia um bom desenvolvedor de um bom. A regra do 'golden hammer' também se aplica - se você tem um desenvolvedor com extenso conhecimento de SQL, é muito provável que este desenvolvedor retire a ferramenta que ele conhece melhor - bancos de dados relacionais - para tentar resolver todos os problemas, embora não necessariamente para ser a melhor solução. Claro, isso também se aplica aos defensores 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 de computadores:

Computer programming (often shortened to programming or coding) is the process of designing, writing, testing, debugging / troubleshooting, and maintaining the source code of computer programs. This source code is written in a programming language. The purpose of programming is to create a program that exhibits a certain desired behavior.

As consultas de banco de dados têm seus próprios idiomas, elas podem ser projetadas, testadas, debugadas e mantidas. A finalidade de uma consulta de 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 empresariais e de negócios (EDIT: especificamente em projetos que utilizam um RDBMS) deve ter conhecimento especializado de 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 projeto de 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 espaço. Procedimentos armazenados complexos, consultas complexas e eficientes e arquitetura e design de software de 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 para software profissional engenheiros que têm experiência com estes offerrings altamente especializados e complicados.

A grande maioria dos sistemas empresariais 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 trabalhei em tais projetos antes que se beneficiou do conhecimento e experiência que essas pessoas trouxeram para o tabela.

Outros já responderam à sua pergunta sobre consultas de 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 de criar um banco de dados.

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

Eu suspeito que há poucos locais de trabalho com um designer de banco de dados dedicado. Então, eu 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 pensamos que cada desenvolvimento gira em torno de um banco de dados e de um banco de dados SQL.

Outros mencionaram as muitas maneiras pelas quais podemos evitar o âmago da questão do SQL em nossos trabalhos, mesmo quando estamos trabalhando (indiretamente) com bancos de dados, mas e sobre todos os desenvolvedores que gravam o firmware para os 101 produtos elétricos? o que 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 diferentes graus, mas está longe de ser um barômetro de sua capacidade.

Acho que você superestima a importância dos bancos de dados no software.

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

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

E quanto aos editores de vídeo lineares e aos mecanismos físicos de videogames?

Espero que um desenvolvedor generalista tenha pelo menos uma consciência das tecnologias de banco de dados (relacionais ou não) e seja capaz de discutir os prós e contras de usá-las. Caso contrário, eu ficaria com medo de que tudo o que eles sabem fazer é inserir dados em arquivos simples.

Eu não acho que a escrita por consulta deva ser um requisito fundamental para programadores. Dito isto, acredito que um programador que pode escrever consultas e projetar bancos de dados seria mais valioso para uma organização.

No entanto, se este programador só pode escrever consultas do tipo "select * from tblxxxx" eu não consideraria este programador como um expert. Da mesma forma, se o banco de dados projetado por este programador colocar relacionamentos um-para-muitos em uma tabela em vez de duas tabelas, não consideraria esse programador um especialista.

Veja como eu explico isso para pessoas que não são de TI. Profissionais de TI se especializam em certas áreas similares a como carpinteiros, eletricistas e encanadores se especializam em campos respeitados. Eles tendem a sobrepor algumas das habilidades, mas não são especialistas em todas as áreas. Um eletricista pode fazer tarefas simples de carpintaria com confiança, mas não seria bom tentar lidar com estruturas complexas.

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

Olhando em volta do nosso departamento, isso depende:

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