Programação / MariaDB

O segredo para um bom banco de dados performático é o equilíbrio

Confira alguns pontos importantes que devem ser levados em consideração na modelagem do seu banco de dados, para que ele tenha performance e também seja dinâmico para receber informações.

Por Gustavo Web

Publicado por Gustavo Web
em 24/05/2017 às 09h00

Lista VIP UpInside

Entre para nossa lista VIP e receba vídeo aulas, artigos e tutoriais exclusivos e com prioridade

  QUERO ENTRAR
Compartilhe:

Salve salve galera, Gustavo Web mais uma vez com um assunto bastante requisitado quando o assunto é banco de dados!

O que fazer para ter um banco de dados com boa performance?

Te juro, uma galeeeera veio me perguntar quais as vantagens e desvantagens de ter o banco de dados normalizado! Temos uma live agendada (depende de quando você está lendo esse artigo...) e o pessoal tem me perguntado bastante itens como:

"Quero aprender as 5FN"

"Qual a vantagem de normalizar um banco de dados?"

"Porque não utilizar um campo multivalorado?"

A galera está no pique para compreender como funciona a normalização do banco... Mas deixa eu te contar um segredo, o mundo lindo dos bancos normalizados funciona melhor nos livos do que na prática!

Isso porque a normalização, nada mais é do que adequar o seu banco para atender 5 regras (chamadas de formas normais) que tem como objetivo manter o seu banco de dados organizado evitando redundância de informações e perca de dados.

De forma bem básica, o processo consiste em criar tabelas para criar os relacionamentos necessários dentro de um banco! E como aquele velho ditado diz: "Tudo o que é em excesso, acaba estragando!".

Normalização x Desempenho

Assim que você entra no processo de normalização e começa a definir os relacionamentos da sua aplicação, você tem por resultado a criação de diversas tabelas. E quando você vai efetuar uma consulta por exemplo, é necessário que você coloque essas tabelas (em ordem cronológica e hierarquica) dentro dos seus JOIN's... Ao fazer isso, você perde performance, afinal o SGDB terá que levar em consideração essas tabelas a mais criadas na sua estrutura.

Portanto, é mais eficaz você entender a regra de negócio e desenvolver uma modelagem do banco de dados que atenda a necessidade do seu cliente de forma otimizada... Do que aplicar as 5FN (formas normais) e acabar tendo perda no desempenho... Ou seja, equilíbrio!

Responsabilidade da aplicação x  Responsabilidade do SGDB

Um item que eu abordei bastante aqui nos artigos também é que você pode passar algumas responsabilidades da sua aplicação para o seu banco de dados. Assim, o consumo que você teria com a linguagem de programação dentro de um loop pode ser passado para o SGDB processar e já entregar as informações praticamente que prontas para seu app! Com isso você pode ter um ganho expressivo de performance no seu banco... Ou seja, equilíbrio!

Organização e Padronização

Obviamente que o seu banco de dados deve ter as tabelas com objetivos bem definidos. Utilizar campos multivalorados (assim como a dúvida do nosso moquerido do print), não é uma boa prática a se aplicar! O ideal é ter uma entidade (tabela) responsável por guardar cada tipo de informação... Se é necessário guardar pessoa jurídica e pessoa física, você precisa estudar se o ideal é salvar essas informações em tabelas diferentes ou se for na mesma tabela, ter campos específicos para cada tipo de dado.

Criar tabela para tudo não é legal, mas também usar um mesmo campo para salvar duas informações distintas não é o correto... Ou seja, equilíbrio!

Análise Técnica

Sempre revisar os índices, JOIN's, relacionamentos, e processos da ferramenta afim de sempre buscar um melhor caminho para executar os procedimentos

E se você curtiu esses artigos você já sabe né? Deixa seu comentário aqui abaixo! Você pode utilizar os comentários também para fazer perguntas ou sugestões de próximos tópicos para eu abordar aqui no blog... Vai que o próximo artigo é respondendo a sua questão :)

Compartilhe:

Em Programação:

Deixe seu comentário: