Quão profundamente programador deve saber sobre internals do mecanismo de banco de dados? [fechadas]

4

Estou aprendendo o SQL Server 2012 junto com o C #. No passado, eu fiz uma aula de banco de dados na faculdade e compreendo bem a linguagem SQL e posso escrever consultas. No entanto, olhando para a documentação do SQL Server (ou Oracle), parece que o mecanismo de banco de dados (juntamente com todas as tecnologias que o acompanham) é altamente complexo e requer tempo e esforço significativos para aprender.

Além de escrever consultas SQL, quão profundamente o programador deve saber sobre os componentes internos do mecanismo de banco de dados?

    
por newprint 15.03.2014 / 08:15
fonte

2 respostas

17

Sem uma boa compreensão dos recursos internos do banco de dados, você está destinado a usá-lo de forma inadequada.

Escrever SQL que executa e executa seu trabalho, mas sem criar o índice adequado no banco de dados, pode funcionar no desenvolvimento, mas funciona muito mal na produção, eliminando efetivamente o banco de dados e causando gargalos.

Identificar um gargalo em si mesmo precisa de uma pessoa experiente, já que você pode (falsamente) dizer - bem, eu alcancei a capacidade do meu servidor de banco de dados, eu só preciso aumentá-lo ... o que se traduz em perda de dinheiro e é uma solução de muito curto prazo.

O desempenho não é o único problema que pode surgir - a segurança é um problema principal que pode não ser aparente para o desenvolvedor ingênuo - o mapeamento de O / R e outros frameworks feitos Injeção de SQL e outros ataques de banco de dados menos prevalentes, mas não ter conhecimento de sua existência pode abrir seu aplicativo para ataques muito desagradáveis.

Projetos orientados a DB em grande escala geralmente têm um DBA em tempo integral, cujo trabalho é trabalhar com o arquiteto do sistema no esquema do banco de dados, orientando os desenvolvedores e examinando todas as consultas, corrigindo-os ou adicionando índices onde necessário.

Em projetos menores, uma equipe pode depender da competência de seu próprio desenvolvedor para isso. Isso significa que você deve ser capaz de entender as principais diretrizes e advertências para usar e usar indevidamente seu banco de dados.

Se você trabalha em uma equipe, você pode querer depender de um membro da equipe que seja mais experiente na área de banco de dados do que você, e deixá-lo revisar suas consultas SQL e ajudá-lo a projetá-las.

Espera-se que os desenvolvedores estejam intimamente familiarizados com muitas tecnologias, desde SQL, noSQL, SO, Web Engines, Mobile, etc., e é relativamente fácil obter um protótipo funcional em qualquer um deles para dar a um desenvolvedor a ilusão de proficiência, até que o mesmo código seja confrontado com o ambiente de produção, onde a verdadeira complexidade da tecnologia é revelada ... é melhor você estar preparado!

    
por 15.03.2014 / 08:42
fonte
9

Tão profundamente quanto você tem tempo para. Hoje em dia, há muito desperdício em relação a ser "banco de dados agnóstico", mas, a menos que você goste da idéia de recursos de menor denominador comum que definem seus melhores esforços, você precisa saber como seu banco de dados funciona. Você obterá melhores resultados em projetos não triviais se decidir tornar seu esquema e aplicativo de banco de dados agnóstico em vez de seguir a outra direção.

A última sentença do parágrafo anterior é contra praticamente todo o conhecimento comum da Web 2.0. Vale a pena decidir onde seu projeto se encaixa no continuum "Melhor é melhor" VS "Pior é melhor".

Mas isso não significa que você deve escolher apenas um banco de dados para aprender, e o que eu realmente quero dizer é que você não deve apenas aprender um paradigma de dados. Embora os esquemas relacionais totalmente normalizados sejam sua melhor aposta para entender completamente seus dados, eles não são viáveis para muitas aplicações práticas (mas eles formam um excelente armazenamento permanente de dados, do qual você pode construir depósitos de alta velocidade personalizados para consultas específicas mais tarde, se tem os recursos). Um esquema relacional desnormalizado deliberadamente é normalmente o seu backbone, mas muitas vezes você também precisa de um banco de dados gráfico e - tão importante quanto seu esquema relacional normalizado - provavelmente precisará desenvolver um esquema de serialização as linhas de ASN.1 ou YAML, não XML, btw - data, não documentos). Se você fizer dados geográficos ou espaciais, um armazenamento de dados especializado em GIS poderá rapidamente se tornar uma necessidade também. Os bancos de dados de documentos também podem se tornar necessários se você perceber um dia que o que está fazendo (ou, mais realisticamente, algum aspecto muito carregado do que está fazendo) é, na verdade, armazenamento de documentos e não armazenamento de registros.

Tendo dito tudo isso, você precisará entender o suficiente sobre cada um para escrever uma camada de integridade intra-db (que pode ser assíncrona, portanto não entre em pânico) para que eles não se entendam. Isso requer saber como os bancos de dados funcionam.

Isso parece muito para saber, mas apenas porque é. Os dados são tão importantes. Claro, você pode ser como os caras da Web 2.0 e chutar o seu caminho ... até chegar a uma ideia realmente nova e de repente perceber que você não pode implementar praticamente a sua ideia legal. Os drives de dados usam, e não o contrário, e hoje em dia está ficando cada vez mais curto. Não seja a próxima pessoa que economizou algumas semanas fazendo um estudo genuíno da modelagem de dados (em todas as suas formas) apenas para passar a vida toda reinventando um sistema de gerenciamento de dados que vive apenas dentro do seu projeto único.

Demorei muito para chegar a essa opinião e minha evolução foi lenta. Eu não precisava de todo esse conhecimento de uma só vez; Entender os dados de uma maneira mais completa veio como um efeito colateral de interagir com aspectos mais interessantes dos problemas que emergiram ao longo do tempo enquanto eu trabalhava. (Em particular, no processo de escrever três grandes sistemas de simulação de negócios por mim mesmo.)

EDIT: Vale ressaltar que a razão pela qual eu dei uma menção especial ao modelo relacional é que é possível simular qualquer outro modelo de dados com dados relacionais, mas não necessariamente possível simular todos os outros modelos de dados de todos os outros. . O relacional normalizado é o mais geral e, portanto, o local para começar a aprender como funcionam os bancos de dados e modelos de dados (e esses são ideias relacionadas com bons bancos de dados como Postgres, DB2 e Oracle). Mas relacional puramente normalizado pode às vezes ser como tentar construir um arranha-céu com um canivete suíço se ele for religiosamente adotado. É por isso que eu digo que você deve entender seus dados de uma forma relacional totalmente normalizada, embora você não possa realmente implementá-los dessa maneira (ou mesmo em um banco de dados).

Em termos práticos, se você aprende a teoria dos dados relacionais primeiro, você vai rapidamente aumentar os pontos strongs e os comprometimentos inerentes a sistemas não relacionais (incluindo sistemas com sabor da semana) como CouchDB, AllegroGraph, ObjectDB, etc. e exatamente onde as abstrações do ORM falham (IOW, você saberá exatamente por que 1 classe! = 1 objeto table & 1! = 1 linha (nem mesmo remotamente fechada)) e aprenderá muitas coisas novas sobre programação funcional e imperativa como bem.

    
por 15.03.2014 / 11:58
fonte