Consultoria DBA SQL Server

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ê.