ASPECTO.Net – Notícias

Em Noções básicas de modelagem de dados apresentei questões teóricas apenas, sem nenhum exemplo prático, já que considerei que aqueles 3 erros comuns devem, primeiro, ser superados. Creio que podemos, agora, partir para um exemplo mais prático.

Uma boa modelagem de banco de dados é de grande valia no desenvolvimento de um site profissional, e essa modelagem não é algo exatamente simples. Muitos acabam modelando razoavelmente bem os bancos de dados simples por algo que poderíamos chamar de ‘talento natural’. Aqui eu pretendo dar um exemplo básico, onde alguns têm acertado, mas a grande maioria realmente erra. Esse errar não significa, necessariamente, que o site não vá funcionar. Nesse caso específico, e realmente muito comum, gera um desperdício de espaço, e até mesmo dificuldade na manutenção. Passemos, então ao exemplo, a partir do cadastro de usuários gratuitos do ASPECTO.Net.

Considerando apenas o ID e os campos preenchidos pelo usuário, e deixando de fora os campos com fins de estatísticas e os campos de controle temos o seguinte:

• ID
• Username
• E-mail
• Senha
• Nome
• País
• Cidade
• Idade
• Sexo
• Lista de discussão
• Fala inglês?

O campo ID é gerado automaticamente, e não há nada especial sobre os campos username, email, senha e nome, que são campos texto. O campo sexo, que é uma seleção, oferece as opções ‘Masculino’ e ‘Feminino’. O que é armazenado, no entanto, é o valor ‘1′ ou ‘2′, que ocupa apenas uma posição. Não faria sentido criar um campo com 9 posições (tamanho da palavra ‘Masculino’) se somente 2 opções são possíveis. Na opção ‘altera cadastro’ o conteúdo é verificado, e se for ‘1′ já seleciona ‘Masculino’. No caso de ‘2′ seleciona ‘Feminino’. Algo parecido acontece com o campo ‘idade’ (faixa etária, na verdade), com a diferença que são 7 as opções e não apenas duas. Os campos ‘Lista de discussão’ e ‘Fala inglês’ também oferecem apenas 2 opções, mas são do tipo ‘checkbox’ porque são lógicos. O usuário fará parte da lista de discussão, ou não. O usuário fala inglês, ou não.

O campo ‘país’ segue o exemplo de ‘idade’, só que com um número de opções ainda maior, mas ainda assim limitado. Na dinâmica de nosso mundo, hoje, a qualquer momento pode surgir um novo país, e acontecendo isso o seu nome será incluído na lista de seleção. Já o campo ‘cidade’ considera algo ainda mais importante na modelagem, e é esse o ponto em que muitos ‘erram’, no sentido de não otimizar os recursos da máquina, como o espaço em disco.

O número de opções para Cidade, ainda que não infinito, é bastante grande. Considerando que existem usuários em muitos países, não podemos oferecer uma lista com opções. Criar um campo texto, de tamanho 30 (ou mais) para armazenar a cidade seria um desperdício de espaço, e é ponto em que muitos ‘erram’. Teríamos muitos registros com o campo cidade preenchido com ‘Rio de Janeiro’, ‘São Paulo’, ‘Porto Alegre’, ‘Belo Horizonte’, ‘Beijing’ (Pequim), ‘London’, ‘New York’, entre outras. O que fazemos, nesse caso, é criar uma tabela com um campo numérico (ID) e um campo texto (30 posições, no nosso caso). No momento em que um usuário se cadastra a cidade que ele informou é procurada nessa tabela. No caso de ser encontrada, o ID dela será lançado no campo cidade (numérico) da tabela de usuários. Caso não seja encontrada ela será incluída e seu ID será lançado na tabela de usuários, uma vez que passou a existir. Dessa forma, estaremos utilizando um campo numérico, poupando muitos bytes, porque temos cada cidade registrada uma única vez em uma tabela e o seu ID utilizado quantas vezes forem necessárias, em um campo da tabela principal. Para a alteração do cadastro fazemos o inverso: procuramos a cidade cujo ID está na tabela de usuários, e lançamos o seu nome no campo texto próprio.

Vamos dar uma olhada, agora, em como ficaria a sintaxe da consulta, uma vez que a modelagem acima esteja sendo utilizada. Nesse caso vamos considerar que a tabela cidades tenha os seguintes campos:

• ID
• cidade

Na tabela cidades, se o registro cujo ID for 1 tiver, como conteúdo do campo cidade, ‘Rio de Janeiro’, os usuários do Rio de Janeiro terão 1 no campo cidade da tabela usuarios. Para selecionarmos todos os usuários da cidade do Rio de Janeiro a sintaxe seria a seguinte:

“SELECT * FROM usuarios INNER JOIN cidades ON usuarios.Cidade = cidades.ID WHERE cidades.cidade = ‘Rio de Janeiro’”

Em um site realmente dinâmico, a expressão ‘Rio de Janeiro’ não estaria no código, mas seria o conteúdo de uma variável. Algo como…

“SELECT * FROM usuarios INNER JOIN cidades ON usuarios.Cidade = cidades.ID WHERE cidades.cidade = ‘” & strCidade & “‘”