Se você está trabalhando com um banco de dados que armazena centenas de registros ou milhões de registros, o design adequado do banco de dados é sempre importante. Não apenas facilitará a recuperação das informações, mas também simplificará a expansão do banco de dados no futuro. Infelizmente, é fácil cair em algumas armadilhas que podem dificultar as coisas no futuro.
Existem livros inteiros escritos sobre o tema da normalização de um banco de dados, mas se você simplesmente evitar os erros comuns mostrados aqui, você estará no caminho certo para um bom design de banco de dados.
Erro de banco de dados # 1: repetindo campos em uma tabela
Uma regra básica para um bom design de banco de dados é reconhecer dados repetidos e colocar essas colunas repetitivas em sua própria tabela. Repetir campos em uma tabela é comum para aqueles que vieram do mundo das planilhas, mas enquanto as planilhas tendem a ser planas, os bancos de dados devem ser relacionais. É como ir de 2D para 3D.
Felizmente, os campos repetitivos são geralmente fáceis de detectar. Basta dar uma olhada nesta tabela:
| OrderID | Produto1 | Produto2 | Produto3 |
| 1 | Ursinhos de pelúcia | Jujubas | |
| 2 | Jujubas |
O que acontece quando um pedido contém quatro produtos? Precisamos adicionar outro campo à tabela para suportar mais de três produtos. E, se tivermos criado um aplicativo cliente ao redor da tabela para nos ajudar a inserir dados, talvez seja necessário modificá-lo com o novo campo do produto. E como encontramos todos os pedidos com Jellybeans na ordem? Seríamos obrigados a consultar todos os campos do produto na tabela com uma instrução SQL que poderia se parecer com: SELECT * FROM Produtos WHERE Product1 = 'Jelly Beans' OU Product2 = 'Jelly Beans' OU Produto3 = 'Jelly Beans'.
Em vez de ter uma única tabela que agregue todas as informações juntas, devemos ter três tabelas que contêm uma informação distinta. Neste exemplo, gostaríamos de uma tabela Pedidos com informações sobre o próprio pedido, uma tabela Produtos com todos os nossos produtos e um tablet ProductOrders que vinculasse produtos ao pedido.
| OrderID | Identificação do Cliente | Data do pedido | Total |
| 1 | 7 | 1/24/17 | 19.99 |
| 2 | 9 | 1/25/17 | 24.99 |
| ID do produto | produtos | Contagem |
| 1 | Ursinhos de pelúcia | 1 |
| 2 | Jujubas | 100 |
| ProductOrderID | ID do produto | OrderID |
| 101 | 1 | 1 |
| 102 | 2 | 1 |
Observe como cada tabela possui seu próprio campo de ID exclusivo. Esta é a chave primária. Nós vinculamos tabelas usando um valor de chave primária como uma chave estrangeira em outra tabela. Leia mais sobre chaves primárias e chaves estrangeiras.
Erro de banco de dados # 2: incorporando uma tabela em uma tabela
Este é outro erro comum, mas nem sempre se destaca tanto quanto os campos repetitivos. Ao projetar um banco de dados, você deseja garantir que todos os dados em uma tabela estejam relacionados a ele. É como o jogo dessa criança sobre identificar o que é diferente. Se você tem uma banana, um morango, um pêssego e um aparelho de televisão, o aparelho de televisão provavelmente pertence a outro lugar.
Na mesma linha, se você tiver uma tabela de vendedores, todas as informações nessa tabela devem se relacionar especificamente a essa pessoa de vendas. Qualquer informação extra que não seja exclusiva dessa pessoa de vendas pode pertencer a outro local do banco de dados.
| SalesID | Primeiro | Último | Endereço | Número de telefone | Escritório | Número do escritório |
| 1 | Sam | Elliot | 118 Main St, Austin, TX | (215) 555-5858 | Austin Downtown | (212) 421-2412 |
| 2 | Alice | Smith | 504 2nd Street, Nova Iorque, NY | (211) 122-1821 | Nova Iorque (leste) | (211) 855-4541 |
| 3 | Joe | Freguesia | 428 Aker St, Austin, TX | (215) 545-5545 | Austin Downtown | (212) 421-2412 |
Embora essa tabela pareça estar relacionada ao vendedor individual, ela realmente tem uma tabela incorporada na tabela. Observe como o Office e OfficeNumber repetem com "Austin Downtown". E se um número de telefone do escritório mudar? Você precisaria atualizar todo um conjunto de dados para uma única alteração de informação, o que nunca é uma coisa boa. Esses campos devem ser movidos para sua própria tabela.
| SalesID | Primeiro | Último | Endereço | Número de telefone | OfficeID |
| 1 | Sam | Elliot | 118 Main St, Austin, TX | (215) 555-5858 | 1 |
| 2 | Alice | Smith | 504 2nd Street, Nova Iorque, NY | (211) 122-1821 | 2 |
| 3 | Joe | Freguesia | 428 Aker St, Austin, TX | (215) 545-5545 | 1 |
| OfficeID | Escritório | Número do escritório |
| 1 | Austin Downtown | (212) 421-2412 |
| 2 | Nova Iorque (leste) | (211) 855-4541 |
Esse tipo de design também oferece a capacidade de adicionar informações adicionais à tabela do Office sem criar um pesadelo de confusão na tabela de vendas. Imagine quanto trabalho seria simplesmente acompanhar o endereço, a cidade, o estado e o código postal se todas essas informações estivessem na tabela de vendedores!
Erro de banco de dados # 3: colocando dois ou mais pedaços de informação em um único campo
Incorporar as informações do escritório na tabela do vendedor não era o único problema com esse banco de dados. O campo de endereço continha três informações: o endereço da rua, a cidade e o estado. Cada campo no banco de dados deve conter apenas uma única informação. Quando você tem várias informações em um único campo, pode ficar mais difícil consultar informações no banco de dados.
Por exemplo, e se quiséssemos fazer uma consulta em todos os vendedores de Austin? Precisamos pesquisar no campo de endereço, que não é apenas ineficiente, mas pode retornar informações incorretas. Afinal, o que acontece se alguém morasse na rua Austin, em Portland, Oregon?
Aqui está a aparência da tabela:
| SalesID | Primeiro | Último | Endereço 1 | Endereço 2 | Cidade | Estado | Fecho eclair | telefone |
| 1 | Sam | Elliot | 118 Main St | Austin | TX | 78720 | 2155555858 | |
| 2 | Alice | Smith | 504 2nd St | Nova york | Nova Iorque | 10022 | 2111221821 | |
| 3 | Joe | Freguesia | 428 Aker St | Apt 304 | Austin | TX | 78716 | 2155455545 |
Há algumas coisas a serem observadas aqui.Primeiro, "Endereço1" e "Endereço2" parecem estar sob o erro de campos repetitivos.
No entanto, neste caso, eles estão se referindo a partes separadas de dados que se relacionam diretamente com o vendedor, em vez de um grupo repetido de dados que devem ir em sua própria tabela.
Além disso, como um erro de bônus a ser evitado, observe como a formatação do número de telefone foi removida da tabela. Você deve evitar armazenar o formato dos campos sempre que possível. No caso de números de telefone, existem várias maneiras pelas quais as pessoas escrevem um número de telefone: 215-555-5858 ou (215) 555-5858. Isso tornaria a busca por uma pessoa de vendas por seu número de telefone ou fazendo uma pesquisa de pessoas de vendas no mesmo código de área mais difícil.
Erro de banco de dados # 4: não usando uma chave primária correta
Na maioria dos casos, você desejará usar um número de incremento automático ou outro número gerado ou alfanumérico para sua chave primária. Você deve evitar usar qualquer informação real para a chave primária, mesmo que soe como se fosse um bom identificador.
Por exemplo, cada um de nós tem nosso próprio número de seguridade social, portanto, usar o número do seguro social para um banco de dados de funcionários pode parecer uma boa ideia. Mas, embora seja raro, até mesmo um número de previdência social pode ser alterado, e nunca queremos que nossa chave primária seja alterada.
E esse é o problema com o uso de informações reais como um valor-chave. Isso pode mudar.
Erro de banco de dados # 5: não usando uma convenção de nomenclatura
Isso pode não parecer grande coisa quando você começa a projetar seu banco de dados, mas quando chegar ao ponto de gravar consultas no banco de dados para recuperar informações, ter uma convenção de nomenclatura ajudará a memorizar nomes de campos.
Imagine o quão difícil seria esse processo se os nomes fossem armazenados como FirstName, LastName em uma tabela e first_name, last_name em outra tabela.
As duas convenções de nomenclatura mais populares são capitalizar a primeira letra de cada palavra no campo ou separar palavras usando um sublinhado. Você também pode ver alguns desenvolvedores capitalizando a primeira letra de cada palavra, exceto a primeira palavra: firstName, lastName.
Você também desejará decidir usar nomes de tabelas singulares ou nomes de tabelas plurais. É uma tabela de pedidos ou uma tabela de pedidos? É uma tabela de clientes ou tabela de clientes? Novamente, você não quer ficar preso a uma tabela Order e a uma tabela Customers.
A convenção de nomenclatura que você escolhe não é tão importante quanto o processo de realmente escolher e aderir a uma convenção de nomenclatura.
Erro de banco de dados # 6: indexação incorreta
A indexação é uma das coisas mais difíceis de acertar, especialmente para os novos no design de banco de dados. Todas as chaves primárias e chaves estrangeiras devem ser indexadas. Estas são as tabelas de links juntas, portanto, sem um índice, você verá um desempenho muito ruim do banco de dados.
Mas o que muitas vezes são perdidas são os outros campos. Estes são os campos "WHERE". Se você costuma restringir sua pesquisa usando um campo em uma cláusula WHERE, você quer pensar em colocar um índice nesse campo. No entanto, você não quer indexar excessivamente a tabela, o que também pode prejudicar o desempenho.
Como decidir? Isso faz parte da arte do design de banco de dados. Não há limites rígidos em quantos índices você deve colocar em uma tabela. Primeiramente, você deseja indexar qualquer campo que seja freqüentemente usado em uma cláusula WHERE. Leia mais sobre indexar corretamente seu banco de dados.
