Você ainda não é assinante?
A EXIBIÇÃO DESTE CONTEÚDO FOI INTERROMPIDAEste post está disponível para assinantes MVPSaiba mais

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

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.

A EXIBIÇÃO DESTE CONTEÚDO FOI INTERROMPIDAEste post está disponível para assinantes MVPSaiba mais