Evite modelar tabelas com muitos campos
![As solicitações do cliente devem ser analisadas com cuidado As solicitações do cliente devem ser analisadas com cuidado](http://arquivo.devmedia.com.br/naoexclusivo/EstevaoDias/DevCast-4DicasBd/slide1-image1.jpg)
![Ou uma única tabela pode acabar armazenando atributos de mais de uma entidade Ou uma única tabela pode acabar armazenando atributos de mais de uma entidade](http://arquivo.devmedia.com.br/naoexclusivo/EstevaoDias/DevCast-4DicasBd/slide1-imagem2.jpg)
Entendeu o que a gente vai fazer? Tem coisa aí de cliente e usuário. Vamos separar em duas tabelas quem é para não dar problema.
A presença de muitos campos em uma mesma tabela pode indicar um problema na modelagem do banco de dados. É possível que atributos de diferentes entidades tenham se misturado, tornando sua representação física menos coesa. Para resolver essa questão podemos criar novas tabelas e relacionamentos, de acordo com a necessidade.
Considere a tabela Cliente apresentada na Figura 1. Perceba que concentramos as credenciais de acesso de um usuário e os dados pessoais de um cliente em um mesmo local. Em circunstâncias normais, nas quais a desnormalização não é uma prioridade, esses dados deveriam estar em tabelas diferentes.
![Tabela Cliente](http://arquivo.devmedia.com.br/naoexclusivo/JoelRodrigues/DevCast/Quatro-Dicas-BancosDeDados/table_cliente.png)
Nesta segunda abordagem, separamos as informações do cliente e do usuário em duas tabelas distintas. Com isso temos tabelas menores, mais fáceis de manter e com o volume necessário de dados, o que pode impactar na performance das consultas. Veja como ficou o modelo na Figura 2.
![Tabelas Cliente e Usuario](http://arquivo.devmedia.com.br/naoexclusivo/JoelRodrigues/DevCast/Quatro-Dicas-BancosDeDados/tabelas_cliente_usuario.png)
Em alguns casos pode ser necessário desnormalizar uma tabela para melhorar a performance da aplicação. Porém a desnormalização precisa ser uma decisão consciente, tomada após compreender o real propósito de cada tabela no banco de dados. Sendo assim, se você se deparar com tabelas muito grandes e não houver registro de desnormalização, considere rever a modelagem do banco de dados, como demonstrado nessa seção.
Defina o COLLATION adequadamente
![Pesquisa com collation Case Sensitive Pesquisa com collation Case Sensitive](http://arquivo.devmedia.com.br/naoexclusivo/JoelRodrigues/DevCast/Quatro-Dicas-BancosDeDados/topico2-slide1.png)
![Pesquisa com collation Case Insensitive Pesquisa com collation Case Insensitive](http://arquivo.devmedia.com.br/naoexclusivo/JoelRodrigues/DevCast/Quatro-Dicas-BancosDeDados/topico2-slide2.png)
Collation é uma configuração do banco de dados que define a forma como os campos do tipo texto serão tratados. Ou seja, se se haverá diferenciação entre letras maiúsculas e minúsculas, bem como entre letras com e sem acento.
Quando usamos um collation CASE SENSITIVE (CS) as letras maiúsculas e minúsculas serão tratadas como diferentes. Logo, se fizermos uma busca por “jose” e no banco de dados constar “JOSE” ou “Jose”, o registro não será localizado. Para evitar esse comportamento devemos escolher um collation CASE INSENSITIVE (CI), que não diferencia letras maiúsculas de minúsculas.
O mesmo é válido para os acentos: um collation ACCENT SENSITIVE tratará como diferentes os caracteres com e sem acento. Logo, se buscarmos por “Jose” e no banco estiver “José”, não localizaremos o dado desejado. Isso pode ser evitado com um collation ACCENT INSENSITIVE (AI).
Com certa frequência, para contornar a dificuldade que surge ao usar collations CS e AS, aplicamos funções para equalizar os dois lados da comparação: o valor buscado e o valor da coluna. Por exemplo, convertemos os dois lados para maiúsculo ou minúsculo, o que acaba causando um processamento adicional que pode prejudicar o desempenho da consulta.