Dicas SQL Server

Projetando um Banco de Dados: 7 Coisas Que Você Não Deve Fazer

Projetando um Banco de Dados: 7 Coisas Que Você Não Deve Fazer

Vamos verificar uma lista de sete coisas que você realmente não quer fazer se estiver projetando um banco de dados.

1. Faça tudo você mesmo

O design do banco de dados é algo que, sem dúvida, deve-se deixar para um profissional e não algo que você deve fazer por si mesmo.

Só porque você pode fazer algo não significa que você deveria. Se você não projetou um banco de dados antes, não torne o seu primeiro projeto um sistema de missão crítica. Saia e contrate um especialista para ajudar a orientá-lo.

2. Não ter expectativas de desempenho

Se você não definiu nenhuma expectativa de desempenho, espere algumas dores de cabeça durante os estágios iniciais da implantação. Da mesma forma, se você tem grandes expectativas de desempenho, você deve esperar algumas decepções, especialmente se você não fez nenhum teste de estresse.

As chances são de que o sistema de teste com dez linhas de dados não seja uma boa indicação de como os milhões de linhas na produção se comportarão.

3. Desprezar o tamanho do dado

Muitas vezes vejo tipos de dados sendo escolhidos como se não importassem. Mas a verdade é que o tamanho é importante.

Se você sabe que os únicos valores possíveis para uma determinada coluna estão entre 0 e 100.000, então você não precisa colocar um tipo de dados BIGINT para aquela coluna quando um INT faria muito bem.

Por que isso importa? O tipo de dados BIGINT requer 8 bytes de armazenamento e o INT requer apenas 4 bytes de armazenamento. Isso significa que para cada linha de dados você pode estar perdendo 4 bytes.

Escolher o tipo de dados correto é importante, por todos os motivos. Por isso, aproveite o tempo e faça um esforço para acertar no início.

4. Não examinar chaves estrangeiras como parte de sua estratégia de indexação

Eu vi muitos bancos de dados que tem pouca ou nenhuma chave primária, chaves estrangeiras ou até mesmo quaisquer índices definidos.

Supondo que você tenha FKs definidos, então você deve avaliar se faria sentido adicionar índices para corresponder a essas definições de FK. Em alguns casos, será. Em outros casos, não será. Mas você deve ter certeza de que esse tipo de revisão é parte de seu processo geral de design.

5. Indexando cada coluna ou indexando nenhuma coluna

Supondo que você tenha definido alguns benchmarks de desempenho realistas, provavelmente vai querer considerar a construção de alguns índices.

Se você não tiver nenhum índice definido, provavelmente não estará preocupado com o desempenho de qualquer maneira. O que eu vejo na maior parte do tempo são bancos de dados com muitos índices definidos.

Isso geralmente é o resultado de alguém usar uma ferramenta de consultoria de ajuste de índice, mas pode ser o caso de alguém ler uma postagem no blog que diz “índices são o que você precisa” e criar uma dúzia de índices em um esforço para obter uma consulta para executar mais rapidamente.

Embora um índice seja maravilhoso para ajudá-lo a ler os dados mais rapidamente, ele adiciona uma sobrecarga para cada instrução.

Adicionar um índice a todas as colunas de uma tabela provavelmente será um pesadelo para qualquer processo que tenha dados entrando nessa tabela.

6. Não levar em conta a qualidade dos dados

Como DBA, entendi que meu papel era focado na recuperação. Se o sistema estivesse inoperante, eu precisava recuperar os dados rapidamente. Esse foi o meu foco principal. Os designers de banco de dados não precisam se preocupar com a recuperação de dados e, em vez disso, eles se concentram na integridade dos dados.

Se você está projetando um banco de dados, então você precisa ter certeza de que você levou em conta a qualidade dos dados.Você simplesmente não pode esperar que outra pessoa faça isso por você.

7. Não há retenção de dados ou estratégia de arquivamento

Se você perguntar a alguém por quanto tempo precisa manter registros de qualquer sistema, a resposta quase sempre volta “sete anos”. Ainda que a resposta real esteja próxima a sete semanas.

Como resultado, os sistemas são construídos com apenas uma coisa em mente: armazená-lo e preservá-lo em tabelas para todos os tempos.

Se você estiver projetando um banco de dados, precisará gastar tempo para descobrir exatamente quantos dados serão retidos. Essa informação vai ajudá-lo a projetar expectativas de desempenho à medida que você armazena mais e mais dados.

Projetando um banco de dados: Conclusão

Se acaso você estiver fazendo qualquer uma dessas sete coisas projetando um banco de dados, é provável que com o tempo, o design do seu banco de dados se torne cada vez mais distante do ideal.

Por isso, simplesmente evitar essas sete coisas impediria o banco de dados de degradação do desempenho ao longo do tempo.

Projetando um Banco de Dados: 7 Coisas Que Você Não Deve Fazer
The following two tabs change content below.

Wesley Mota

DBA SQL Server
Profissional graduado em Banco de Dados e Sistemas de Informação com mais de 7 anos de experiência em empresas de software. Certificado MCSA Microsoft SQL Server possui intensa vivência em administração de banco de dados, Tunning, Performance SQL Server, levantamento de melhorias e monitoramento de banco de dados e servidores SQL Server. Consultoria SQL Server em diversos clientes no Brasil e ao redor do mundo. Escritor no blog dbasqlserverbr.com.br/blog. Onde compartilha conhecimento, experiências e dicas de performance para DBAs SQL Server. Conhecimentos em Oracle e ambientes de alta disponibilidade. Desenvolvimento de softwares web e mobile.Gerenciamento de equipe e projetos.

Latest posts by Wesley Mota (see all)