O campo ID é gerado automaticamente, e não há nada especial sobre os campos username, email, senha e nome, que 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ção (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 to 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 é o 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 outro 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.