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

35

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.

database query

— Shamim Hafiz
fonte

2

O que você quer dizer com "estrutura"? Se você está falando de semântica, compreender qualquer tipo de nova semântica não deve ser um problema para um " especialista ". Por definição. OTOH, apenas alguns desenvolvedores estão expostos a bancos de dados e linguagens de consulta, o resto de nós não se importa.

— SK-lógica

3

Eu acho que essa é uma suposição errônea: "Existem tantos programadores por aí que também são especialistas em criação de consultas e design de banco de dados". Existem relativamente poucos programadores especialistas nessas coisas: DBA! = SE.

— Ashley

11

Quão difícil é realmente escrever consultas no banco de dados?

— Capitão Sensible

@CaptainShakespeare, realmente pode ficar bastante difícil depois que você passar pelas operações CRUD. Ty fazendo relatórios complexos algum dia. E, em seguida, observe as consultas de ajuste de desempenho.

— HLGEM

69

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:

Eles geralmente são inexperientes.
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 .

— Matthew Rodatus
fonte

11

Então, se alguém fez um projeto não trivial que usava o Banco de Dados, é esperado que ele se familiarize com as consultas, certo?

— Shamim Hafiz

3

@ Shamim, eu esperaria que essa pessoa tenha experiência moderada em consultas, a menos que essa pessoa seja do nível júnior ou de nível básico. Talvez essa pessoa tenha apenas alguns anos de experiência e estivesse abrigada em uma equipe altamente especializada?

— Maple_shaft

12

@ Shamim eu provavelmente esperaria isso. Eles ainda poderiam ser um bom programador. Perguntas como essa são muito difíceis de responder, porque são muitas advertências: talvez a equipe tenha um programador de banco de dados; talvez a falta de trivalidade do aplicativo estivesse na lógica de negócios e as consultas ao banco de dados fossem triviais; talvez eles tenham distribuído o trabalho de forma que seu programador não trabalhasse nas consultas; etc.

— Matthew Rodatus

4

Minha equipe de desenvolvimento dedicou programadores PL / SQL como parte do projeto. Portanto, enquanto os programadores .Net podem fazer consultas simples, eles existem para revisá-lo e desenvolver as consultas mais complexas. Além disso, com a proliferação do ORM (e NOSQL), por que você acha que desenvolvedores não-SQL precisam conhecer consultas complexas.

— softveda

2

@ Matthew Rodatus: Eu trabalhei em locais que tinham bibliotecas que gerenciavam consultas, então seria teoricamente possível trabalhar lá sem entender o SQL simples. Acredito que todos os desenvolvedores foram competentes na prática.

— David Thornley

23

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.

— wolfgangsz
fonte

11

Felizmente, hoje em dia é perfeitamente aceitável fazer aplicativos sem nenhum RDBMS. A maioria das tarefas não precisa delas ou simplesmente não pode ser mapeada adequadamente para um modelo relacional. Existem inúmeras opções de armazenamento não relacional disponíveis.

— 8609 SK-logic

8

Isso resume minha opinião também. Especialista? Não. Conhecimento? Sim.

— Wayne Molina

2

@ SK-logic, Que tipos de opções você acha que tornam irrelevantes os bancos de dados relacionais? O datawarehousing é especializado demais para que a análise seja útil em um sistema transacional. E não me inicie em tudo errado com o OODBMS.

— Maple_shaft

11

@maple_shaft, existem inúmeras soluções de armazenamento especializadas e orientadas ao domínio. RDBMSes tenta ser genérico e falha muito nisso. Em alguns casos, mesmo os DBMS hierárquicos antigos são muito melhores que relacionais.

— SK-logic

6

Nem todo software de desktop usa bancos de dados; portanto, tenha cuidado ao dizer que isso acontece o tempo todo.

— Adam Lear

18

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.

— HLGEM
fonte

4

+1 por mencionar que a presença de um ORM não substitui a necessidade de conhecer o SQL (ou os fatores subjacentes em qualquer tipo de banco de dados que você estiver usando).

— precisa saber é o seguinte

4

+1 e gostaria de poder dar mais 100! Eu conheço essa correlação! = Causalidade, mas é mais do que aparente para mim que os desenvolvedores de aplicativos mais eficazes com os quais já trabalhei tinham um entendimento completo de como escrever uma consulta SELECT padrão. Eu deveria ser capaz de entregar a um bom desenvolvedor um modelo de dados e uma "pergunta" sobre os dados, e essa pessoa poderá, eventualmente, escrever uma consulta que "responda" à minha pergunta.

— Maple_shaft

11

+1, concordo totalmente. Não compreendo a explicação de que 'usamos ORM' ou 'temos programadores dedicados para isso'. Se alguém é realmente experiente , ele teria preenchido o papel de desenvolvedor de banco de dados em um ponto. É isso que é experiência.

— GrandmasterB

15

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.

— Cthulhu
fonte

Os bancos de dados NoSQL não processam mais dados ou mais rápido que os bancos de dados relacionais. Não sei onde você ouviu isso, mas é flagrantemente, perigosamente errado.

— Aaronaught

@Aaronaught - Editado, obrigado pelo aviso de minha suposição prematura, :).

— Cthulhu

7

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.

— guiman
fonte

7

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.

— maple_shaft
fonte

2

-1: discordo totalmente de que um "bom" engenheiro de software seja especialista em consultas de bancos de dados relacionais.

— John Saunders

3

Você ainda discorda se eu disser que é um bom engenheiro de software de aplicativos ENTERPRISE ou BUSINESS (ao contrário de sistemas embarcados, etc ...) e se eu disser que essa pessoa deve ser especialista em consultas de banco de dados relacionais STANDARD (sem fornecedor de calças extravagantes) específicos, como consultas analíticas e afins)? Um entendimento completo das instruções SQL SELECT, todos os tipos de junções, uniões, interseções e mesclagens, visualizações em linha, condições, conjuntos de resultados de pedidos e agrupamentos deve ser completamente compreendido e amplamente demonstrado por QUALQUER engenheiro de software que possua as etiquetas especificadas acima.

— Maple_shaft

4

Meh. Eu trabalho em uma grande empresa de software e não lidamos com nenhum RDBMS. Meu último trabalho no desenvolvimento de software para desktop também não exigia nenhum SQL. Não tenho certeza de como você define aplicativos corporativos e de negócios, mas parece-me que sua visão sobre as coisas é um pouco estreita.

— Adam Lear

2

Eu mantenho o que disse. Teoricamente, se o aplicativo for bem hierarquizado e componente, não há necessidade, no entanto, em toda a minha experiência profissional, minha equipe e eu teríamos DROWNED se não fôssemos especialistas em SQL, mesmo quando tivéssemos uma equipe dedicada ao design e desenvolvimento de RDBMS. Talvez eu seja antiquado ou apenas tenha uma péssima sorte na minha carreira?

— Maple_shaft

3

@ maple_shaft Sim, não é que os aplicativos em que trabalhei tenham sido suficientemente componentes. É que eles não usaram nenhum RDBMS, ponto final. Campos diferentes, eu acho. O ponto é que você não pode dizer que todo desenvolvedor de negócios / empresa deve ser bom em SQL. Simplesmente não é verdade. Seja bom nisso se você o usar. Não se preocupe demais se não precisar até precisar, como em qualquer outro idioma ou tecnologia.

— Adam Lear

6

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.

— Gilbert Le Blanc
fonte

5

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.

— cjmUK
fonte

5

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?

— Alex Jasmin
fonte

5

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.

— Barry Brown
fonte

4

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.

— Michael Riley - também conhecido por Gunny
fonte

3

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.

— Carra
fonte