Artigos Banco de Dados Quatro dicas de banco de dados
Você ainda não é assinante?

Evite modelar tabelas com muitos campos


As solicitações do cliente devem ser analisadas com cuidado Ou uma única tabela pode acabar armazenando atributos de mais de uma entidade
#PraCegoVer - Transcrição dos Slides Daí eu vou precisar armazenar no sistema o nome, e-mail, senha, função, endereço... esses dados do cliente, entende?
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
Figura 1. Tabela Cliente

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
Figura 2. Tabelas Cliente e Usuario

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 Insensitive

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.