Evite modelar tabelas com muitos campos
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.
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.
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
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.
