Suponha que estamos usando java ou python para acessar o banco de dados. Então é considerado um desperdício de tempo e desnecessário aprender o tipo de estruturas e objetos de dados que estão sendo usados ​​dentro do sql?

Por favor, responda em referência à indústria de software. Por favor, tente dizer em quais casos será bom ter conhecimento dessas coisas.

Eu tenho uma discussão com alguém que diz que é desnecessário aprender essas coisas.

Alguns anos atrás, trabalhei em um aplicativo que foi escrito por alguém que claramente nunca havia aprendido como os bancos de dados SQL funcionam. Recebi um relatório de problemas para corrigir - a página principal de resumo do status, que sempre fora lenta, agora estava tão lenta que estava atingindo o tempo limite de execução do script do servidor (de 3 minutos) durante a renderização. Parecia que, à medida que o número de clientes no sistema aumentava, o tempo para renderizar a página de status aumentava quadraticamente .

Não demorou muito tempo para perceber o problema, que era que a página usava uma consulta que reunia dados de duas tabelas diferentes, nenhuma das quais tinha índices . Como cada tabela tinha tamanho que crescia em O (n) com o número de clientes, a consulta estava demorando O (n ^ 2) para ser executada porque estava buscando cada linha da primeira tabela e, para cada uma dessas linhas, estava buscando todas as linhas da segunda tabela para compará-las.

A solução do problema levou alguns minutos, e qualquer um que entenda como os bancos de dados SQL funcionam seria capaz de fazê-lo com a mesma rapidez . O autor original não, então deixou para trás uma solução totalmente inadequada.

Você precisa entender como (pelo menos em termos gerais) uma tecnologia funciona para evitar cometer erros horrendos como esse.

Não descarte a possibilidade de precisar acessar o banco de dados e consultá-lo diretamente como parte de um processo de depuração. Se você sempre acaba fazendo isso, você definitivamente vai querer saber tudo sobre a tecnologia de banco de dados e como o seu banco de dados específico está estruturado. Talvez isso não aconteça. Mas se isso acontecer (e, na minha experiência, sempre acontece em algum momento), você precisará desse conhecimento.

Mas vamos supor que você nunca precisará procurar diretamente no banco de dados por qualquer motivo. Digamos que você esteja usando o ORM de maneira consistente com todas as melhores práticas estabelecidas pela comunidade. Você pode criar um aplicativo de alto desempenho sem grandes erros / gargalos / ineficiências gravados nos dados. Mas se você realmente não entender o banco de dados subjacente, não entenderá realmente por que está fazendo as coisas do jeito que está. Pior, você realmente nãoentender como as práticas recomendadas se aplicam ao seu caso de uso específico. Esses fatos devem gerar dúvidas de que você está criando a solução ideal. Sua solução pode funcionar, mas você não poderá dizer "esta é a melhor solução" com confiança real. Se você não pode dizer isso, não é um grande trunfo aos olhos da sua empresa e, se diz isso e está errado, isso será terrível para você.

Além das discussões filosóficas que tenho sobre não aprender os fundamentos de sua pilha de tecnologia, trato de razões tangíveis para conhecer sua pilha de cima para baixo diariamente. Na minha empresa, temos um enorme monólito lidando com enormes quantidades de dados. As coisas são modeladas bem, mas existem dezenas e dezenas de tipos de objetos no aplicativo e os relacionamentos entre eles são uma incrível rede de chaves estrangeiras e tabelas de associação. Francamente, se você nunca procurar no SQL e apenas mergulhar no aplicativo (embora tudo esteja modelado corretamente no aplicativo e use o ORM e as práticas recomendadas estabelecidas para esse ORM), descubra como obter essas informações nesse outro ponto. aqui pode ser uma tarefa quase impossível. Mas se você puder mergulhar no banco de dados, poderá ver todos os campos em cada modelo, seguir as conexões entre tabelas, descubra um caminho de uma peça para a outra, teste-a com uma consulta e encontre os modelos adequados para fazer isso através do ORM de maneira rápida e eficiente. Eu não seria metade do patrimônio da minha empresa se não tivesse um alto nível de conforto com o SQL bare-metal.

Somente até certo ponto

Como desenvolvedor de software, você provavelmente precisará consultar e atualizar o banco de dados, e saber como o banco de dados opera é essencial para evitar consultas ruins, junções ineficientes e assim por diante. Você pode ter um DBA dedicado que pode decidir onde adicionar índices e particionar o banco de dados, mas não pode contar com ele, nem em pequenas empresas e nem sempre em grandes empresas.

Contudo

Embora você deva saber o que são índices e como eles devem ser usados, provavelmente não precisa saber como eles funcionam internamente. Os detalhes da implementação interna são exatamente isso - detalhes da implementação.

Saber como verificar um plano de consulta SQL e criar seu código de acordo é parte da API que seu banco de dados expõe. Conhecendo os algoritmos internos e as estruturas de dados que ele usa para alcançá-lo? Não. Muito. Como analogia, eu deveria conhecer as implicações de desempenho de salvar arquivos em disco. Não preciso me preocupar com como meu sistema de arquivos é implementado.

No entanto, para o porém

Se, como mostram os comentários esclarecedores, a pergunta é sobre como entender o acesso ao banco de dados versus confiar exclusivamente em ORMs e outras abstrações de código, a resposta é predominantemente "sim, você deve saber o acesso ao banco de dados". Nem todo projeto usa ou pode usar um ORM, e os ORMs não são ideais para determinadas tarefas (relatórios, inserções em massa e muito mais).

É absolutamente vale o tempo! Ser um desenvolvedor de pilha completa permite produzir com eficiência soluções de valor agregado. Vi muitas vezes falhas de comunicação e desenvolvimento de silos ... Triplicar o tempo de desenvolvimento e metade da qualidade.

No final do dia, quanto mais habilidades você tiver, mais valioso será.

Se você professa não saber nada sobre carros , eu ficaria feliz em você consertar os freios nos meus? Eu acho que não.

Os bancos de dados são visivelmente diferentes das estruturas de dados com as quais você está acostumado a trabalhar na programação. Eles têm suas próprias esquisitices e idiossincrasias e outras coisas que o morderão no desempenho do aplicativo, se você não entender.

Encontrei pessoas com essa mentalidade de "não preciso conhecer bancos de dados"; a maioria deles considera os bancos de dados como nada além de planilhas e produz aplicativos com um desempenho espantosamente ruim como resultado.

Dito isto, você não precisa saber como os bancos de dados funcionam internamente .

Você começa a conhecer o material lógico; Tabelas, índices, visualizações e similares.

Não fique preso nos detalhes da implementação de como um DBMS específico lida com essas coisas; todos eles fazem de maneira diferente um do outro (e às vezes entre versões deles !), portanto, uma "visão geral" geral o servirá melhor.

Você absolutamente precisa saber. Por exemplo, se seu banco de dados estiver armazenando datas, você precisará saber que tipo de precisão pode esperar. Se você estiver armazenando um registro de data e hora em um DATEcampo, deve saber se o banco de dados truncará seu valor para o segundo mais próximo (ou pior, o dia mais próximo). Você também deve saber que os valores provenientes de uma NUMBER(9,2)coluna precisam ser armazenados em uma variável de ponto flutuante, enquanto os valores em a NUMBER(15,0)podem ser armazenados como números inteiros. Você também pode achar útil conhecer pequenas curiosidades, como as CHARcolunas do Oracle, preenchidas com espaço em branco no comprimento especificado, enquanto as VARCHAR2colunas não. E o LONGtipo de dados deles na verdade armazena cadeias de comprimento variável, não números.

Todo banco de dados tem suas peculiaridades, e você deve saber o que são (ou pelo menos o que procurar).

Compreender como as coisas funcionam sob o capô o ajudará a depurar suas consultas por considerações de desempenho e armazenamento.

Por exemplo, uma consulta de intervalo terá melhor desempenho com um tipo de índice de árvore B. E ao fazer junções, você pode adicionar dicas ao mecanismo de consulta sobre se deseja usar junções HASH ou MERGE. E no lado físico, você pode distribuir tabelas em um banco de dados para diferentes partições de disco físico para minimizar a contenção de cabeça (provavelmente ainda adequada mesmo com SSDs).

Primeiro, você precisa ter clareza sobre o que é e o que não é o SQL. SQL é uma linguagem de consulta e linguagem de manipulação de dados usada para acessar e manipular dados em um banco de dados relacional. Mas o esquema e os objetos de dados (tabelas, colunas, índices, restrições) no banco de dados não estão "no SQL", o SQL é apenas uma linguagem possível para consultar e manipular os dados.

Para poder trabalhar efetivamente com um banco de dados relacional, você precisa entender tabelas, colunas, tipos de dados, chaves primárias, chaves estrangeiras e índices. Você também precisa entender o básico da consulta: projeção, filtros, junções. Você precisa entender o básico da normalização.

Mas nenhuma dessas coisas, em princípio, exige que você toque em SQL. Você pode criar o esquema do banco de dados em um designer de GUI e escrever consultas e atualizações em algum outro idioma, como SqlAlchemy para Python ou Linq para .net. Alguns até argumentam que essas linguagens são uma representação mais pura do modelo relacional do que o SQL.

Então, em teoria, seu amigo está certo - você não precisa aprender SQL. Mas você ainda precisa aprender como os bancos de dados relacionais funcionam e, quando você sabe disso, o SQL é muito fácil de aprender, pois é apenas uma sintaxe.

Embora não seja necessário, é bastante conveniente conhecer o SQL, pois você pode consultar qualquer banco de dados diretamente no SQL sem a necessidade de uma camada de tradução separada. E como todos os tutoriais, livros e exemplos usam SQL, será difícil evitar aprendê-lo.

Encontrei um problema em que os números de série estavam sendo armazenados como números decimais de 10 dígitos em um banco de dados e lidos em números inteiros de 32 bits em Java. Isso foi bom até atingirmos o nosso primeiro número de série maior que 2G, por isso não pôde ser representado no número inteiro assinado de Java de 32 bits. A compreensão dos tipos de dados do banco de dados pode ter evitado esse problema.