Semana passada um colega passou por uma situação interessante: perdeu o controle de uma coluna auto incrementável de suma importância, que culminou com a interrupção de um serviço on-line importante. Ora, faz parte do papel do DBA manter os dados sob rédea curta, sob controle, mesmo que às vezes eles se comportem como um cavalo doido, e, tente se comportar à margem das Leis de Murphy, Moore, dentre tantas outras.
Fazer colunas maiores do que, realmente, elas precisam ser é um grande desperdício de recurso. Principalmente, no MySQL, onde temos uma grande variedade de tipos de dados (data types).
Colunas menores ocupam menos espaço em disco, em memória, e, acima de tudo geram menos I/O. Na verdade, a diminuição de I/O é a nossa maior e legitima preocupação, quando entra em pauta o assunto “data types”.
Todo mundo tem uma coluna “id” para chamar de “sua“. Pelo menos, se, minimamente, utiliza-se alguma das formas normais. Sem teorizar muito: toda tabela deveria ter uma coluna que identifica-se (id) uma linha de forma indelével (é, não faz parte do meu tradicional repertório, é efeito do filme Amour). Em outras palavras, é uma coluna que garante singularidade máxima a uma linha, candidatíssima a chave primária, de valor único e inconfundível! Uma maneira de o MySQL prover uma chave destas, é através do uso de AUTO INCREMENT e PRIMARY KEY.
