O que todo desenvolvedor deve saber sobre bancos de dados? [fechadas]

206

Quer gostemos ou não, muitos, se não a maioria de nós, desenvolvedores trabalham regularmente com bancos de dados ou podem ter que trabalhar com um dia. E considerando a quantidade de mau uso e abuso na natureza e o volume de perguntas relacionadas ao banco de dados que surgem todos os dias, é justo dizer que existem certos conceitos que os desenvolvedores devem conhecer - mesmo que não projetem ou trabalhem com eles. bancos de dados hoje. Assim:



Quais são os conceitos importantes que desenvolvedores e outros profissionais de software devem conhecer sobre bancos de dados?


Diretrizes para Respostas:


Mantenha sua lista curta.
Um conceito por resposta é o melhor.

Seja específico .
"Modelagem de dados" pode ser uma habilidade importante , mas o que isso significa exatamente?

Explique sua lógica.
Por que seu conceito é importante? Não basta dizer "usar índices". Não se enquadre nas "melhores práticas". Convença seu público a aprender mais.

Respostas positivas com as quais você concorda.
Leia as respostas de outras pessoas primeiro. Uma resposta de alta classificação é uma afirmação mais eficaz do que duas de baixa classificação. Se você tiver mais a acrescentar, adicione um comentário ou faça referência ao original.

Não diminua o voto de algo apenas porque não se aplica a você pessoalmente.
Todos trabalhamos em diferentes domínios. O objetivo aqui é orientar os iniciantes em bancos de dados a obter uma compreensão bem fundamentada e abrangente do design e desenvolvimento orientados a bancos de dados, para não competir pelo título de mais importante.

Aaronaught
fonte
15
Por que votar para fechar isso ?? É uma comunidade Wikia e, portanto, apropriada.
David
5
Vou votar para reabrir se ele for fechado ... Eu também gostaria de ver uma lista daquilo que os DBAs devem (mas não sabem) sobre OOP e aplicativo / design de software de sistemas / ..
Charles Bretana
7
@gnovice: A palavra "subjetivo" nesse contexto refere-se a perguntas que são inteiramente uma questão de opinião. "O que você acha do livro de Joe Celko?" - essa é uma pergunta subjetiva. Essa pergunta está solicitando informações objetivas; acontece que não existe uma resposta "certa". Eu acho que é importante dar um passo atrás e perguntar: "isso é apenas brincadeira ociosa ou é útil para alguns desenvolvedores?" Meus dois centavos de qualquer maneira - não é como se eu estivesse ganhando pontos por isso. :-)
Aaronaught 30/12/2009
6
Pessoalmente, eu odeio essas perguntas. Quase sempre equivalem a montes de opiniões pessoais, luz sobre informações úteis e pesadas declarações subjetivas. Mas não estou disposto a fechá-lo apenas por esse motivo; ele poderia estar a meio caminho decente, Aaron, se você definir algumas diretrizes para respostas: respostas ao tópico único (o que você deve saber e por que você deve saber), sem duplicatas, up-voto o que concordam com ... e mais importante, mova suas próprias opiniões em respostas que demonstrem isso. Tal como está, parece um post de blog ou discussão no fórum, nenhum dos quais tem nenhum negócio com SO.
30909 Shog9
4
Acho isso interessante: "É um Wiki da comunidade e, portanto, apropriado". Como diabos uma CW pode torná-la apropriada? Uma pergunta é apropriada ou não, e acho que essa é uma maneira subjetiva de ser útil se alguém estiver procurando por uma resposta. Pode ser interessante, mas essa não é a única característica que uma pergunta deve ter.
Georg Schölly 30/12/2009

Respostas:

106

A primeira coisa que os desenvolvedores devem saber sobre bancos de dados é: para que servem os bancos de dados ? Não como eles funcionam, nem como você constrói um, nem como você escreve código para recuperar ou atualizar os dados em um banco de dados. Mas para que servem?

Infelizmente, a resposta para este é um alvo em movimento. No auge dos bancos de dados, da década de 1970 ao início da década de 90, os bancos de dados eram para o compartilhamento de dados. Se você estava usando um banco de dados e não estava compartilhando dados, estava envolvido em um projeto acadêmico ou estava desperdiçando recursos, inclusive você. Configurar um banco de dados e domesticar um DBMS eram tarefas tão monumentais que o retorno, em termos de dados explorados várias vezes, tinha que ser enorme para corresponder ao investimento.

Nos últimos 15 anos, os bancos de dados passaram a ser usados ​​para armazenar os dados persistentes associados a apenas um aplicativo. A criação de um banco de dados para MySQL , Access ou SQL Server se tornou tão rotineira que os bancos de dados se tornaram quase uma parte rotineira de um aplicativo comum. Às vezes, essa missão limitada inicial é empurrada para cima pela fluência da missão, à medida que o valor real dos dados se torna aparente. Infelizmente, os bancos de dados projetados com um único objetivo em mente frequentemente falham drasticamente quando começam a ser empurrados para uma função que é essencial para toda a empresa e de missão crítica.

A segunda coisa que os desenvolvedores precisam aprender sobre bancos de dados é toda a visão centrada em dados do mundo. A visão de mundo centrada em dados é mais diferente da visão de mundo centrada em processos do que qualquer coisa que a maioria dos desenvolvedores já aprendeu. Comparado a essa lacuna, a lacuna entre programação estruturada e programação orientada a objetos é relativamente pequena.

A terceira coisa que os desenvolvedores precisam aprender, pelo menos em uma visão geral, é a modelagem de dados, incluindo modelagem conceitual de dados, modelagem lógica de dados e modelagem física de dados.

A modelagem de dados conceitual é realmente uma análise de requisitos do ponto de vista centralizado em dados.

A modelagem de dados lógicos geralmente é a aplicação de um modelo de dados específico aos requisitos descobertos na modelagem de dados conceitual. O modelo relacional é usado muito mais do que qualquer outro modelo específico, e os desenvolvedores precisam aprender o modelo relacional com certeza. Projetar um modelo relacional poderoso e relevante para um requisito não trivial não é uma tarefa trivial. Você não pode criar boas tabelas SQL se não entender bem o modelo relacional.

A modelagem de dados físicos geralmente é específica do DBMS e não precisa ser aprendida com muitos detalhes, a menos que o desenvolvedor também seja o construtor de banco de dados ou o DBA. O que os desenvolvedores precisam entender é até que ponto o design do banco de dados físico pode ser separado do design lógico do banco de dados e até que ponto a produção de um banco de dados de alta velocidade pode ser realizada apenas aprimorando o design físico.

A próxima coisa que os desenvolvedores precisam aprender é que, embora a velocidade (desempenho) seja importante, outras medidas de qualidade do design são ainda mais importantes , como a capacidade de revisar e estender o escopo do banco de dados mais adiante ou a simplicidade da programação.

Finalmente, qualquer pessoa que mexa com os bancos de dados precisa entender que o valor dos dados geralmente ultrapassa o sistema que os capturou .

Uau!

Walter Mitty
fonte
Muito bem escrito! E a perspectiva histórica é ótima para pessoas que não estavam trabalhando no banco de dados naquele momento (eu).
`` #
6
Bem escrito. E acho que seu último ponto é ignorado com muita frequência por pessoas que tentam "apenas fazê-lo".
DaveE 30/12/2009
1
Há uma conexão entre o que escrevi e tópicos como Explain Plan, Indexing e Data Normalization. Eu adoraria discutir essa conexão com mais profundidade em algum tipo de fórum de discussão. SO não é um fórum.
Walter Mitty 01/01
1
Se você achou que estava lendo esse monstro, imagine como foi escrevê-lo! Não me propus a escrever um ensaio. Depois que comecei, parecia fluir. Quem adicionou o negrito realmente ajudou os leitores, IMO.
Walter Mitty
3
@Walter Você forneceu explicações para todos os seus pontos, exceto este: "A segunda coisa que os desenvolvedores precisam aprender sobre bancos de dados é a visão global centrada em dados. A visão centrada em dados é mais diferente da visão centrada em processos do que qualquer coisa que a maioria dos desenvolvedores já tenha aprendido. Comparada a essa lacuna, a lacuna entre programação estruturada e programação orientada a objetos é relativamente pequena ". Você poderia elaborar isso? Você declarou que a diferença é grande, mas acho que gostaria de realmente entender a visão centrada em dados e como ela é separada da visão do processo.
precisa saber é o seguinte
73

Boa pergunta. A seguir, alguns pensamentos em nenhuma ordem específica:

  1. A normalização, pelo menos para a segunda forma normal, é essencial.

  2. A integridade referencial também é essencial, com considerações de exclusão e atualização em cascata adequadas.

  3. Uso bom e adequado de restrições de verificação. Deixe o banco de dados fazer o máximo de trabalho possível.

  4. Não espalhe a lógica de negócios no banco de dados e no código da camada intermediária. Escolha um ou outro, de preferência no código da camada intermediária.

  5. Decida uma abordagem consistente para chaves primárias e chaves em cluster.

  6. Não exagere. Escolha seus índices com sabedoria.

  7. Nomeação consistente de tabela e coluna. Escolha um padrão e cumpri-lo.

  8. Limite o número de colunas no banco de dados que aceitarão valores nulos.

  9. Não se empolgue com gatilhos. Eles têm seu uso, mas podem complicar as coisas com pressa.

  10. Tenha cuidado com UDFs. Eles são ótimos, mas podem causar problemas de desempenho quando você não sabe com que frequência eles podem ser chamados em uma consulta.

  11. Obtenha o livro da Celko sobre design de banco de dados. O homem é arrogante, mas sabe as coisas dele.

Randy Minder
fonte
1
gostaria de elaborar o item 4. Esse é um tópico que sempre me intrigou.
Brad
9
@ David: Eu sempre preferi colocá-lo em ambos os lugares. Dessa forma, você estará protegido contra erros e também contra erros do usuário. Não há motivo para tornar todas as colunas anuláveis ​​ou para permitir que valores fora do intervalo de 1 a 12 sejam inseridos em uma Monthcoluna. Regras comerciais complexas são, é claro, outra história.
Aaronaught 30/12/2009
1
@ Brad - A maioria das nossas aplicações em trabalho foi realizada bem antes de processos sólidos de programação serem implementados. Portanto, temos lógica de negócios espalhadas por toda parte. Algumas delas estão na interface do usuário, outras na camada intermediária e outras no banco de dados. É uma bagunça. Na IMO, a lógica de negócios pertence à camada intermediária.
Randy Minder
2
@ David - Se é uma certeza absoluta que modificações no banco de dados ocorrerão apenas em aplicativos, então você pode estar certo. No entanto, isso é provavelmente muito raro. Como os usuários provavelmente inserem dados diretamente no banco de dados, é uma boa prática colocar a validação no banco de dados também. Além disso, alguns tipos de validação são simplesmente realizados com mais eficiência no banco de dados.
Randy Minder
1
O ponto 8 é realmente importante. Como acertar os tipos de coluna em geral, é uma coisa muito importante a saber.
21410 Chris
22

Primeiro, os desenvolvedores precisam entender que há algo a saber sobre bancos de dados. Eles não são apenas dispositivos mágicos nos quais você coloca o SQL e obtém conjuntos de resultados, mas peças de software muito complicadas com lógica e peculiaridades próprias.

Segundo, que existem diferentes configurações de banco de dados para diferentes propósitos. Você não deseja que um desenvolvedor faça relatórios históricos de um banco de dados transacional on-line se houver um data warehouse disponível.

Terceiro, os desenvolvedores precisam entender o SQL básico, incluindo junções.

Depois disso, depende de quão estreitamente os desenvolvedores estão envolvidos. Eu trabalhei em empregos onde eu era desenvolvedor e DBA de fato, onde os DBAs estavam no final do corredor e onde os DBAs estão em sua própria área. (Não gosto do terceiro.) Supondo que os desenvolvedores estejam envolvidos no design do banco de dados:

Eles precisam entender a normalização básica, pelo menos as três primeiras formas normais. Qualquer coisa além disso, consiga um DBA. Para quem tem experiência com tribunais dos EUA (e programas aleatórios de televisão contam aqui), há o mnemônico "Depende da chave, de toda a chave e nada além da chave, então ajude-o a Codd".

Eles precisam ter uma idéia sobre os índices, com o que quero dizer que eles devem ter alguma idéia de quais índices precisam e como provavelmente afetarão o desempenho. Isso significa não ter índices inúteis, mas não ter medo de adicioná-los para ajudar nas consultas. Qualquer coisa adicional (como a balança) deve ser deixada para o DBA.

Eles precisam entender a necessidade de integridade dos dados e apontar para onde estão verificando os dados e o que estão fazendo se encontrarem problemas. Isso não precisa estar no banco de dados (onde será difícil emitir uma mensagem de erro significativa para o usuário), mas precisa estar em algum lugar.

Eles devem ter o conhecimento básico de como obter um plano e como lê-lo em geral (pelo menos o suficiente para saber se os algoritmos são eficientes ou não).

Eles devem saber vagamente o que é um gatilho, o que é uma visão e que é possível particionar partes de bancos de dados. Eles não precisam de nenhum tipo de detalhes, mas precisam saber para perguntar ao DBA sobre essas coisas.

É claro que eles devem saber que não devem se intrometer nos dados de produção, no código de produção ou em algo assim, e devem saber que todo o código-fonte entra em um VCS.

Sem dúvida, esqueci algo, mas o desenvolvedor médio não precisa ser um DBA, desde que haja um DBA real em mãos.

David Thornley
fonte
19

Indexação básica

Fico sempre chocado ao ver uma tabela ou um banco de dados inteiro sem índices ou índices arbitrários / inúteis. Mesmo se você não estiver projetando o banco de dados e apenas precisar escrever algumas consultas, ainda é vital entender, no mínimo:

  • O que é indexado no seu banco de dados e o que não é:
  • A diferença entre os tipos de verificações, como são escolhidas e como a maneira como você escreve uma consulta pode influenciar essa escolha;
  • O conceito de cobertura (por que você não deveria apenas escrever SELECT *);
  • A diferença entre um índice em cluster e não em cluster;
  • Por que índices mais / maiores não são necessariamente melhores;
  • Por que você deve tentar evitar agrupar colunas de filtro em funções.

Os designers também devem estar cientes dos anti-padrões comuns de índice, por exemplo:

  • O antipadrão do Access (indexação de todas as colunas, uma por uma)
  • O antipadrão Catch-All (um índice massivo em todas ou na maioria das colunas, aparentemente criado com a impressão equivocada de que aceleraria todas as consultas concebíveis que envolvam qualquer uma dessas colunas).

A qualidade da indexação de um banco de dados - e se você aproveita ou não as consultas que você escreve - é, de longe, a parte mais significativa do desempenho. 9 de 10 perguntas postadas no SO e em outros fóruns que reclamam de desempenho ruim invariavelmente se devem a indexação ruim ou a uma expressão não sargável.

Aaronaught
fonte
Você pode elaborar sobre "cobertura"? Percebo por que o SELECT * não é um bom hábito, mas não sei o significado de "cobertura" e me pergunto se isso se refere a outro motivo para evitar o SELECT *.
Edmund
1
@ Edmund: Um índice cobre uma consulta se todos os campos de saída fizerem parte do índice (como colunas indexadas ou INCLUDEcolunas no SQL Server). Se o único índice disponível para uma determinada consulta não for coberto, todas as linhas deverão ser recuperadas uma a uma, o que é uma operação muito lenta e, na maioria das vezes, o otimizador de consulta decidirá que não é. vale a pena e faça uma varredura completa de índice / tabela. É por isso que você não escreve SELECT *- praticamente garante que nenhum índice cubra a consulta.
Aaronaught
obrigado! Embora, como usuário do PostgreSQL, não precise me preocupar com essas coisas (ainda?): Os índices não contêm informações de visibilidade; portanto, as tuplas da tabela sempre precisam ser verificadas também. Em geral, porém, parece um fator muito importante.
Edmund
@ Edmund: O PostgreSQL pode não ter INCLUDEcolunas (não tenho certeza), mas isso não significa que você não pode colocar as colunas que deseja cobrir nos dados reais do índice. Isso foi o que tivemos que fazer nos dias do SQL Server 2000. A cobertura ainda é importante, não importa em que DBMS você esteja.
Aaronaught
16

Normalização

Sempre me deprime ver alguém lutando para escrever uma consulta excessivamente complicada que seria completamente direta com um design normalizado ("Mostre-me o total de vendas por região").

Se você entender isso desde o início e projetar adequadamente, poupará muita dor depois. É fácil desnormalizar o desempenho após a normalização; não é tão fácil normalizar um banco de dados que não foi projetado dessa maneira desde o início.

No mínimo, você deve saber o que é 3NF e como chegar lá. Na maioria dos bancos de dados transacionais, esse é um equilíbrio muito bom entre facilitar a gravação de consultas e manter um bom desempenho.

Aaronaught
fonte
14

Como funcionam os índices

Provavelmente não é o mais importante, mas com certeza o tópico mais subestimado.

O problema com a indexação é que os tutoriais SQL geralmente não os mencionam e que todos os exemplos de brinquedos funcionam sem nenhum índice.

Desenvolvedores ainda mais experientes podem escrever SQL razoavelmente bom (e complexo) sem saber mais sobre índices do que " Um índice torna a consulta rápida ".

Isso ocorre porque os bancos de dados SQL fazem um trabalho muito bom trabalhando como caixa preta:

Diga-me o que você precisa (gimme SQL), eu vou cuidar disso.

E isso funciona perfeitamente para recuperar os resultados corretos. O autor do SQL não precisa saber o que o sistema está fazendo nos bastidores - até que tudo se torne tãããããão ...

É quando a indexação se torna um tópico. Mas isso geralmente é muito tarde e alguém (alguma empresa?) Já está sofrendo de um problema real.

É por isso que acredito que a indexação é o principal tópico a não esquecer ao trabalhar com bancos de dados . Infelizmente, é muito fácil esquecê-lo.

aviso Legal

Os argumentos são emprestados do prefácio do meu e-livro gratuito " Use The Index, Luke ". Estou gastando bastante tempo explicando como os índices funcionam e como usá-los corretamente.

Markus Winand
fonte
12

Eu só quero salientar uma observação - ou seja, parece que a maioria das respostas assume que o banco de dados é intercambiável com os bancos de dados relacionais. Também existem bancos de dados de objetos, bancos de dados de arquivos simples. É importante avaliar as necessidades do projeto de software em questão. Do ponto de vista do programador, a decisão do banco de dados pode ser adiada até mais tarde. A modelagem de dados, por outro lado, pode ser alcançada desde o início e levar a muito sucesso.

Penso que a modelagem de dados é um componente-chave e é um conceito relativamente antigo, mas que foi esquecido por muitos na indústria de software. A modelagem de dados, especialmente a modelagem conceitual, pode revelar o comportamento funcional de um sistema e pode ser considerada um roteiro para o desenvolvimento.

Por outro lado, o tipo de banco de dados necessário pode ser determinado com base em muitos fatores diferentes, incluindo ambiente, volume do usuário e hardware local disponível, como espaço no disco rígido.

FernandoZ
fonte
Você quer dizer como fazer diagramas de entidade-relacionamento?
precisa saber é o seguinte
Sim ... eu esqueci de mencionar ERDs :-)?
FernandoZ
+1 ... Mas você deve perceber que está no SO: a casa dos encanadores que passam seus dias corrigindo a incompatibilidade de impedância do ORM para que todos saibam, comam e pensem que não é apenas relacional, mas "SQL" :)
SyntaxT3rr0r
11

Evitando a injeção de SQL e como proteger seu banco de dados

iChaib
fonte
9

Todo desenvolvedor deve saber que isso é falso: "Criar um perfil de uma operação de banco de dados é completamente diferente do código de criação de perfil".

Existe um Big-O claro no sentido tradicional. Quando você faz um EXPLAIN PLAN(ou o equivalente), está vendo o algoritmo. Alguns algoritmos envolvem loops aninhados e são O ( n ^ 2). Outros algoritmos envolvem pesquisas em árvore B e são O ( n log n ).

Isso é muito, muito sério. É central para entender por que os índices são importantes. É fundamental para entender as compensações de velocidade-normalização-desnormalização. É fundamental entender por que um data warehouse usa um esquema em estrela que não é normalizado para atualizações transacionais.

Se você não souber ao certo o algoritmo usado, faça o seguinte. Pare. Explique o plano de execução de consulta. Ajuste os índices de acordo.

Além disso, o corolário: mais índices não são melhores.

Às vezes, um índice focado em uma operação desacelera outras operações. Dependendo da proporção das duas operações, a adição de um índice pode ter bons efeitos, nenhum impacto geral ou prejudicar o desempenho geral.

S.Lott
fonte
Eu tinha a sensação de que seria tomada da maneira errada. O que eu quis dizer com "tradicional" foi que você realmente não tem controle sobre os algoritmos, apenas a capacidade de influenciar quais são usados. De qualquer forma, removi esse idioma porque não quero nada excessivamente controverso no post principal.
Aaronaught 30/12/09
@ Aaron: Você não tem controle sobre os algoritmos. É para isso que servem os índices.
315/09 S.Lott
Hmm, então você pode alterar qual tipo de algoritmo de classificação é usado pelo DE? Quais estruturas de dados são usadas para o índice? Prefiro não discutir sobre esse ponto, é por isso que o retirei, mas defendo a ideia básica de que você tem muito menos controle ao trabalhar com o banco de dados em comparação com o código.
Aaronaught 30/12/2009
@ Aaron: Menos controle não remove a obrigação de realmente entender se a consulta é * O ** (* n ^ 2) ou * O ** (* n log n ) ou apenas ** O ** (n). Menos controle não elimina a obrigação de realmente entender o que está acontecendo e descobrir como controlá-lo.
315/09 S.Lott
@ S.Lott: Acho que estamos do mesmo lado aqui, pois estava sugerindo uma carga maior de criação de perfis para bancos de dados - "Você precisa saber ... [como] ler um plano de consulta". Mas minha edição parece ter sido revertida, então ... acho que agora pertence à comunidade.
Aaronaught 30/12/2009
8

Eu acho que todo desenvolvedor deve entender que os bancos de dados exigem um paradigma diferente .

Ao escrever uma consulta para obter seus dados, é necessária uma abordagem baseada em conjunto. Muitas pessoas com um histórico interativo lutam com isso. E, no entanto, quando a adotam, podem obter resultados muito melhores, mesmo que a solução possa não ser a que se apresentou pela primeira vez em suas mentes focadas na iteração.

Rob Farley
fonte
Por favor, esclareça o que se entende por abordagem "baseada em conjunto"
Vivian River
1
Você deve considerar os dados como estando em conjuntos e considerar seus problemas como potencialmente resolvidos pela aritmética de conjuntos - envolvendo funções de classificação, quando necessário, subconsultas, agregados e assim por diante. Muitos desenvolvedores pensam sobre o que precisa ser feito para cada linha, que é o pensamento iterativo.
Rob Farley
8

Excelente pergunta. Vamos ver, primeiro ninguém deve considerar consultar uma base de dados que não entende completamente as junções. É como dirigir um carro sem saber onde estão o volante e os freios. Você também precisa conhecer os tipos de dados e como escolher o melhor.

Outra coisa que os desenvolvedores devem entender é que há três coisas que você deve ter em mente ao criar um banco de dados:

  1. Integridade dos dados - se os dados não puderem ser confiáveis, você basicamente não possui dados - isso significa não colocar a lógica necessária no aplicativo, pois muitas outras fontes podem tocar no banco de dados. Restrições, chaves estrangeiras e, às vezes, gatilhos são necessários para a integridade dos dados. Não deixe de usá-los porque você não gosta deles ou não quer se incomodar em entendê-los.

  2. Desempenho - é muito difícil refatorar um banco de dados com desempenho insatisfatório e o desempenho deve ser considerado desde o início. Há muitas maneiras de fazer a mesma consulta e algumas são conhecidas por serem mais rápidas quase sempre; é míope não aprender e usar essas maneiras. Leia alguns livros sobre ajuste de desempenho antes de projetar consultas ou estruturas de banco de dados.

  3. Segurança - esses dados são o sangue da vida da sua empresa, mas também freqüentemente contêm informações pessoais que podem ser roubadas. Aprenda a proteger seus dados contra ataques de injeção de SQL e roubo de identidade e fraude.

Ao consultar um banco de dados, é fácil obter a resposta errada. Certifique-se de entender completamente seu modelo de dados. Lembre-se de que muitas vezes as decisões reais são tomadas com base nos dados que sua consulta retorna. Quando está errado, são tomadas as decisões comerciais erradas. Você pode matar uma empresa por perguntas ruins ou perder um grande cliente. Os dados têm significado, os desenvolvedores geralmente parecem esquecer isso.

Os dados quase nunca desaparecem, pense em termos de armazenamento de dados ao longo do tempo, em vez de apenas como obtê-los hoje. Esse banco de dados que funcionou bem quando tinha cem mil registros, pode não ser tão bom em dez anos. Os aplicativos raramente duram tanto quanto os dados. Essa é uma das razões pelas quais o design para desempenho é crítico.

Seu banco de dados provavelmente precisará de campos que o aplicativo não precisa ver. Coisas como GUIDs para replicação, campos de inserção de data. etc. Você também pode precisar armazenar o histórico de alterações e quem as fez quando e conseguir restaurar alterações ruins neste armazém. Pense em como você pretende fazer isso antes de perguntar a um site como corrigir o problema em que você esqueceu de colocar uma cláusula where em uma atualização e atualizou a tabela inteira.

Nunca desenvolva uma versão mais recente de um banco de dados que a versão de produção. Nunca, nunca, nunca se desenvolva diretamente em um banco de dados de produção.

Se você não possui um administrador de banco de dados, verifique se alguém está fazendo backups e sabe como restaurá-los e testou a restauração.

O código do banco de dados é um código, não há desculpa para não mantê-lo no controle de origem, assim como o restante do seu código.

HLGEM
fonte
6

Design Evolucionário de Banco de Dados. http://martinfowler.com/articles/evodb.html

Essas metodologias ágeis tornam o processo de alteração do banco de dados gerenciável, previsível e testável.

Os desenvolvedores devem saber o que é necessário para refatorar um banco de dados de produção em termos de controle de versão, integração contínua e testes automatizados.

O processo Evolucionário de Design de Banco de Dados possui aspectos administrativos, por exemplo, uma coluna deve ser descartada após algum período de vida em todos os bancos de dados dessa base de código.

Pelo menos saiba que existem conceitos e metodologias de Refatoração de banco de dados. http://www.agiledata.org/essays/databaseRefactoringCatalog.html

A classificação e a descrição do processo possibilitam a implementação de ferramentas para essas refatorações.

George Polevoy
fonte
Eu amo o conceito de refatoração, mas em relação ao DB, o grande problema é com os dados persistentes. A refatoração do banco de dados geralmente envolve a migração de dados, o que, na realidade, é difícil, especialmente se você não tiver tempo de inatividade do sistema. também a reversão não é trivial. na minha opinião, dificuldades nas estratégias de rollout + rollback apropriadas / seguras costumam mostrar obstáculos para refatorar o DB tão leve quanto o código do aplicativo. por si só, muitas vezes faz sentido refatorar coisas, mas você sempre deve superar os custos / benefícios.
manuel aldana
Consulte também 'Refatoração de bancos de dados' da Ambler ( amazon.com/Refactoring-Databases-Evolutionary-Database-Design/… ).
Jonathan Leffler
5

Pela minha experiência com bancos de dados relacionais, todo desenvolvedor deve saber:

- Os diferentes tipos de dados :

Usar o tipo correto para o trabalho correto tornará seu design de banco de dados mais robusto, suas consultas mais rápidas e sua vida mais fácil.

- Aprenda sobre 1xM e MxM :

Este é o pão com manteiga para bancos de dados relacionais. Você precisa entender as relações um para muitos e muitos para muitos e aplicá-las quando apropriado.

- O princípio " KISS " também se aplica ao DB :

A simplicidade sempre funciona melhor. Desde que você tenha estudado como o DB funciona, você evitará uma complexidade desnecessária que levará a problemas de manutenção e velocidade.

- índices :

Não basta se você souber o que são. Você precisa entender quando usá-los e quando não.


Além disso:

  • Álgebra booleana é sua amiga
  • Imagens: não os armazene no banco de dados. Não pergunte o porquê.
  • Teste DELETE com SELECT
Um machado
fonte
+1 para Imagens. Eu substituiria 'Imagens' por 'BLOBs'.
precisa saber é o seguinte
Não tenho muita certeza da parte "simplicidade". O banco de dados mais simples possível é uma tabela gigante com várias varchar(max)colunas. Os bancos de dados relacionais devem ser normalizados , não simplificados .
Aaronaught
Suas preocupações são abordadas anteriormente, na parte "tipos de dados" da minha postagem. Eu estava me referindo ao uso (desnecessário) de procedimentos armazenados / gatilhos / cursores e assim por diante.
Anax
5

Gostaria que todos, DBAs e desenvolvedor / designer / arquitetos, entendessem melhor como modelar adequadamente um domínio de negócios e como mapear / traduzir esse modelo de domínio de negócios em um modelo lógico de banco de dados normalizado, um modelo físico otimizado e um modelo de classe orientado a objeto apropriado, cada um dos quais é (pode ser) diferente, por várias razões, e entende quando, por que e como eles são (ou deveriam ser) diferentes um do outro.

Charles Bretana
fonte
5

Eu diria fortes habilidades básicas em SQL. Até agora, vi muitos desenvolvedores que sabem um pouco sobre bancos de dados, mas estão sempre pedindo dicas sobre como formular uma consulta bastante simples. As consultas nem sempre são fáceis e simples. Você precisa usar várias junções (interna, esquerda, etc.) ao consultar um banco de dados bem normalizado.

MaxiWheat
fonte
5

Sobre o seguinte comentário à resposta de Walter M.:

"Muito bem escrito! E a perspectiva histórica é ótima para pessoas que não estavam trabalhando no banco de dados naquele momento (eu)".

A perspectiva histórica é, em certo sentido, absolutamente crucial. "Aqueles que esquecem a história estão fadados a repeti-la." Cfr XML repetindo os erros hierárquicos do passado, bancos de dados gráficos repetindo os erros de rede do passado, sistemas OO forçando o modelo hierárquico aos usuários, enquanto todos com apenas um décimo de cérebro devem saber que o modelo hierárquico não é adequado para representação de propósito do mundo real, etc, etc.

Quanto à própria pergunta:

Todo desenvolvedor de banco de dados deve saber que "Relacional" não é igual a "SQL". Eles entendiam por que estão sendo decepcionados pelos fornecedores de DBMS e por que deveriam dizer a esses mesmos fornecedores que inventassem coisas melhores (por exemplo, DBMS que são realmente relacionais) se eles querem continuar sugando quantidades hilárias de dinheiro de seus clientes para esse software ruim).

E todo desenvolvedor de banco de dados deve saber tudo sobre a álgebra relacional. Então não haveria mais um único desenvolvedor que tivesse que postar essas perguntas estúpidas de "Eu não sei como fazer o meu trabalho e quero que alguém faça isso por mim" no Stack Overflow.

Erwin Smout
fonte
1
Concordo que um desenvolvedor precisa saber onde o SQL e o RDM divergem. Dito isto, o uso criterioso do RDM pode ser um auxílio inestimável para o designer de banco de dados, mesmo que a implementação seja SQL.
22811 Walter Mitty
1
Caso você tenha esquecido, George Santayana, escreveu essa citação clássica ...
crosenblum
5

Acho que muitos detalhes técnicos foram abordados aqui e não quero adicioná-los. A única coisa que quero dizer é mais social do que técnica, não caia na armadilha do "DBA que sabe o melhor" como desenvolvedor de aplicativos.

Se você estiver tendo problemas de desempenho com a consulta, também tome posse do problema. Faça sua própria pesquisa e peça aos DBAs que expliquem o que está acontecendo e como suas soluções estão lidando com o problema.

Crie suas próprias sugestões também depois de fazer a pesquisa. Ou seja, tento encontrar uma solução cooperativa para o problema, em vez de deixar problemas de banco de dados para os DBAs.

HeretoLearn
fonte
boa resposta. Cada um de nós tem sua própria área, contribuímos para todos os problemas ou soluções.
precisa saber é o seguinte
5

Respeito simples.

  • Não é apenas um repositório
  • Você provavelmente não conhece melhor que o fornecedor ou os DBAs
  • Você não vai apoiá-lo às 3 da manhã com os gerentes seniores gritando com você
gbn
fonte
3

Considere a desnormalização como um possível anjo, não o diabo, e também considere os bancos de dados NoSQL como uma alternativa aos bancos de dados relacionais.

Além disso, acho que o modelo de Entidade-Relação é obrigatório para todo desenvolvedor, mesmo que você não crie bancos de dados. Isso permitirá que você entenda completamente o que é seu banco de dados.

iChaib
fonte
3

Nunca insira dados com a codificação de texto incorreta.

Depois que seu banco de dados ficar poluído com várias codificações, o melhor que você pode fazer é aplicar uma combinação de heurística e trabalho manual.

mikerobi
fonte
2
O que é a "codificação de texto incorreta" e como isso acontece?
Gennady Vanin Геннадий Ванин
1
@ vgv8, acontece quando seu cliente permite que os usuários enviem texto em qualquer codificação que você desejar, e você o armazena cegamente. Então, quando você precisar executar algum tipo de transformação ou análise, seu código será interrompido, porque seu aplicativo assume o utf-8, mas algum idiota adicionou dados do utf-16 e o ​​seu programa falha ou começa a cuspir bobagens.
Mckobi #
3

Além das opções conceituais e de sintaxe que eles empregam (como junções, gatilhos e procedimentos armazenados), uma coisa que será crítica para todo desenvolvedor que emprega um banco de dados é o seguinte:

Saiba como seu mecanismo executará a consulta que você está escrevendo com especificidade.

A razão pela qual penso que isso é tão importante é simplesmente a estabilidade da produção. Você deve saber o desempenho do seu código para não interromper toda a execução no encadeamento enquanto aguarda a conclusão de uma longa função. Por que você não gostaria de saber como sua consulta afetará o banco de dados, seu programa e talvez até o servidor?

Na verdade, isso é algo que atingiu minha equipe de P&D mais vezes do que falta ponto e vírgula ou algo parecido. Presume-se que a consulta seja executada rapidamente porque ocorre em seu sistema de desenvolvimento com apenas alguns milhares de linhas nas tabelas. Mesmo que o banco de dados de produção tenha o mesmo tamanho, é muito provável que seja usado muito mais e, portanto, sofra outras restrições, como vários usuários acessando-o ao mesmo tempo, ou algo dando errado com outra consulta em outro lugar, atrasando assim o resultado desta consulta.

Até coisas simples, como como as junções afetam o desempenho de uma consulta, são inestimáveis ​​na produção. Existem muitos recursos de muitos mecanismos de banco de dados que facilitam as coisas conceitualmente, mas podem introduzir obstáculos no desempenho se não forem pensados ​​com clareza.

Conheça o processo de execução do mecanismo de banco de dados e planeje-o.

TodPunk
fonte
3

Para um desenvolvedor profissional intermediário que usa muito bancos de dados (escrevendo / mantendo consultas diariamente ou quase diariamente), acho que a expectativa deve ser a mesma de qualquer outro campo: você escreveu um na faculdade .

Todo nerd de C ++ escrevia uma classe de string na faculdade. Todo nerd de gráficos escreveu um raytracer na faculdade. Todo geek da web escrevia sites interativos (geralmente antes de termos "estruturas da web") na faculdade. Todo nerd de hardware (e até nerd de software) construiu uma CPU na faculdade. Todo médico dissecou um cadáver inteiro na faculdade, mesmo que ela só tome minha pressão arterial e me diga que meu colesterol está muito alto hoje. Por que os bancos de dados seriam diferentes?

Infelizmente, hoje parecem diferentes, por algum motivo. As pessoas querem que os programadores .NET saibam como as strings funcionam em C , mas os internos do seu RDBMS não devem lhe interessar muito .

É virtualmente impossível obter o mesmo nível de entendimento apenas lendo sobre eles ou até mesmo trabalhando de cima para baixo. Mas se você começar de baixo e entender cada parte, será relativamente fácil descobrir as especificidades do seu banco de dados. Até coisas que muitos geeks de banco de dados parecem não gostar, como quando usar um banco de dados não relacional.

Talvez isso seja um pouco rigoroso, especialmente se você não estudou ciência da computação na faculdade. Vou abrandar um pouco: você pode escrever um hoje , completamente, do zero. Não me importo se você souber os detalhes de como o otimizador de consultas do PostgreSQL funciona, mas se você souber o suficiente para escrever um, provavelmente não será muito diferente do que eles fizeram. E você sabe, realmente não é tão difícil escrever um básico.

Ken
fonte
No artigo do Joel vinculado sobre cadeias C, o seguinte trecho de código não leva a um comportamento indefinido: char * str = "* Hello!"; str [0] = strlen (str) - 1; str é uma literal de string e é geral na memória somente leitura. Você não pode escrever para ele :?
HeretoLearn
Um especialista profissional em banco de dados, tudo bem, mas todo desenvolvedor ?
Ben Aston
Ben: Todo desenvolvedor profissional que usa bancos de dados com frequência, sim. Eles realmente não são tão difíceis, então, se você não sabe, significa que você nunca levou um tempo para aprender como os DBs funcionam. Todos os cursos de ciência da computação que me formei projetaram uma CPU e implementaram um sistema operacional. Um banco de dados é mais simples do que qualquer um desses; portanto, se você gastar algum tempo usando um, não vejo uma desculpa para não saber como eles funcionam.
Ken
2

A ordem das colunas em um índice não exclusivo é importante.

A primeira coluna deve ser a coluna que tem maior variabilidade em seu conteúdo (ou seja, cardinalidade).

Isso ajuda a capacidade do SQL Server de criar estatísticas úteis sobre como usar o índice em tempo de execução.

Mike D
fonte
-1 Não é uma boa ideia seguir regras como 'A primeira coluna deve ser a coluna que tem maior variabilidade em seu conteúdo'. Se alguém tem algum conhecimento básico de como os índices funcionam, é simples ver como a ordem é importante e que a ordem da coluna deve depender da maneira como a tabela será consultada.
precisa saber é o seguinte
obrigado, mas se o índice foi criado em 3 campos, com base em que uma consulta sql específica usará esses 3 campos na cláusula where, a ordem pode ser significativa e o campo com a cardinalidade mais alta aparecendo primeiro \ anteriormente pode levar a melhorias de desempenho .... ou pelo menos é o que eu li em um livro de ajuste de desempenho do Microsoft SQL Server. Eu tentei e parecia funcionar melhor (anos atrás).
Mike D
2

Entenda as ferramentas que você usa para programar o banco de dados !!!

Eu perdi muito tempo tentando entender por que meu código estava misteriosamente falhando.

Se você estiver usando o .NET, por exemplo, precisará saber como usar corretamente os objetos no System.Data.SqlClientespaço para nome. Você precisa saber como gerenciar seusSqlConnection objetos para garantir que eles sejam abertos, fechados e, quando necessário, descartados corretamente.

Você precisa saber que quando você usa a SqlDataReader, é necessário fechá-lo separadamente do seu SqlConnection. Você precisa entender como manter as conexões abertas, quando apropriado, para minimizar o número de ocorrências no banco de dados (porque elas são relativamente caras em termos de tempo de computação).

Daniel Allen Langdon
fonte
2
  • Habilidades básicas de SQL.
  • Indexação.
  • Lide com diferentes encarnações de DATE / TIME / TIMESTAMP.
  • Documentação do driver JDBC para a plataforma que você está usando.
  • Lidar com tipos de dados binários ( CLOB , BLOB , etc.)
JuanZe
fonte
1

Para alguns projetos, o modelo Orientado a Objetos é melhor.

Para outros projetos, um modelo relacional é melhor.

Mark Lutton
fonte
1

O problema de incompatibilidade de impedância e conheça as deficiências comuns ou ORMs.

Muhammad Soliman
fonte
1

Compatibilidade com RDBMS

Veja se é necessário executar o aplicativo em mais de um RDBMS. Se sim, pode ser necessário:

  • evitar extensões SQL RDBMS
  • eliminar gatilhos e armazenar procedimentos
  • siga rigorosos padrões SQL
  • converter tipos de dados de campo
  • alterar os níveis de isolamento da transação

Caso contrário, essas perguntas deverão ser tratadas separadamente e diferentes versões (ou configurações) do aplicativo serão desenvolvidas.

Juliano
fonte
1

Não dependa da ordem das linhas retornadas por uma consulta SQL.

Agnel Kurian
fonte
3
... a menos que haja uma ORDER BYcláusula?
Aaronaught 9/07/10
E não usar ORDER BYdesnecessariamente porque acrescenta carga ao servidor SQL
Vivian Rio