Os parênteses em campos numéricos do MySQL
Antes de mais nada, coloquem uma coisa na cabeça: O "range" (valor mínimo e valor máximo) das colunas TINYINT, SMALLINT, MEDIUMINT, INT e BIGINT não alteram, independente do que for colocado entre os parênteses.
Uma coluna definida como INT(1) continua armazenando até o valor 2.147.483.647 ou 4.294.967.295 (caso esteja com o atributo UNSIGNED).
Os parênteses dessas colunas podem ser comparados em parte (eu disse, em parte) com os parênteses de colunas do tipo CHAR. A diferença é que se a coluna for um desses numéricos, o MySQL não irá limitar a quantidade de caracteres do campo (exceto pelo "range", dependendo do tipo, óbvio).
Se você armazenar uma string de 3 caracteres numa coluna CHAR(5), o MySQL irá "preencher" os outros 2 caracteres com espaços, ou seja, sempre irá ocupar esse espaço de 5 caracteres na memória (mesmo que com espaços). Se você tentar armazenar uma string com mais de 5 caracteres, o MySQL irá "cortar" sua string para 5 caracteres, ou seja, se você tentar armazenar a string "código", o MySQL irá gravar "códig".
(Agora a revelação...)
Em uma coluna INT(5), se você armazenar um número de 3 dígitos, o MySQL TAMBÉM irá "preencher" os 2 dígitos restantes com espaços, ocupando SEMPRE, no mínimo, 5 caracteres na memória, assim como na coluna CHAR(5). PORÉM, se você armazenar um número superior a 5 dígitos (dentro do "range" definido pelo INT), o MySQL NÃO irá "cortar" seu número, irá gravar sem problemas. Está duvidando, então façam o teste! :)
Uma coluna definida como INT(1) continua armazenando até o valor 2.147.483.647 ou 4.294.967.295 (caso esteja com o atributo UNSIGNED).
Os parênteses dessas colunas podem ser comparados em parte (eu disse, em parte) com os parênteses de colunas do tipo CHAR. A diferença é que se a coluna for um desses numéricos, o MySQL não irá limitar a quantidade de caracteres do campo (exceto pelo "range", dependendo do tipo, óbvio).
Se você armazenar uma string de 3 caracteres numa coluna CHAR(5), o MySQL irá "preencher" os outros 2 caracteres com espaços, ou seja, sempre irá ocupar esse espaço de 5 caracteres na memória (mesmo que com espaços). Se você tentar armazenar uma string com mais de 5 caracteres, o MySQL irá "cortar" sua string para 5 caracteres, ou seja, se você tentar armazenar a string "código", o MySQL irá gravar "códig".
(Agora a revelação...)
Em uma coluna INT(5), se você armazenar um número de 3 dígitos, o MySQL TAMBÉM irá "preencher" os 2 dígitos restantes com espaços, ocupando SEMPRE, no mínimo, 5 caracteres na memória, assim como na coluna CHAR(5). PORÉM, se você armazenar um número superior a 5 dígitos (dentro do "range" definido pelo INT), o MySQL NÃO irá "cortar" seu número, irá gravar sem problemas. Está duvidando, então façam o teste! :)
gostei do artigo...parabéns...
13/06/2007 12:13am
(~17 anos atrás)
como disseste: "Se você utiliza uma coluna definida como INT(1) para servir como uma "flag" ... podem continuar"
eu acho que para definir uma coluna como "flag" que receberá apenas um valor, esta não é a melhor maneira, porque um campo INT requer 4 bytes para armazenar quaisquer valores dentro do range permitido.
se é pra armazenar somente um número, por exemplo, é melhor utilizar o TINYINT que requer somente 1 byte, além de ter um range (unsigned) de 0 a 255. o que vale também pra tabelas de poucos registros.
claro, tudo isso pensando em uma larga escala de dados. somando, somando.. podem chegar a megas de diferença, ao final.
CHAR(1) também pode ser utilizado como "flag", por necessitar de apenas 1 byte. o lado ruim: só vai aceitar de 0 a 9, enquanto, o lado bom: pode aceitar quaisquer caracteres, não somente numeros. ótimo para "i" (inativo) e "a" (ativo), que dão uma "humanizada" nas informações.
ps.: tem gente que defende o "set" e "enum". eu acho de extremo mau-gosto e também muita mão-de-obra cada vez que se deve adicionar uma opção.
no mais, ótimo artigo.
já tive essa dúvida sobre esses numerozinhos entre parenteses. haha
abraço,
Pablo Dias
eu acho que para definir uma coluna como "flag" que receberá apenas um valor, esta não é a melhor maneira, porque um campo INT requer 4 bytes para armazenar quaisquer valores dentro do range permitido.
se é pra armazenar somente um número, por exemplo, é melhor utilizar o TINYINT que requer somente 1 byte, além de ter um range (unsigned) de 0 a 255. o que vale também pra tabelas de poucos registros.
claro, tudo isso pensando em uma larga escala de dados. somando, somando.. podem chegar a megas de diferença, ao final.
CHAR(1) também pode ser utilizado como "flag", por necessitar de apenas 1 byte. o lado ruim: só vai aceitar de 0 a 9, enquanto, o lado bom: pode aceitar quaisquer caracteres, não somente numeros. ótimo para "i" (inativo) e "a" (ativo), que dão uma "humanizada" nas informações.
ps.: tem gente que defende o "set" e "enum". eu acho de extremo mau-gosto e também muita mão-de-obra cada vez que se deve adicionar uma opção.
no mais, ótimo artigo.
já tive essa dúvida sobre esses numerozinhos entre parenteses. haha
abraço,
Pablo Dias
25/05/2007 5:51pm
(~17 anos atrás)
Eu também pensava dessa forma. Entre o CHAR e VARCHAR já sabia, mas sobre o INT só descobri a pouco tempo, por acaso. Precisando uma solução para ocupar com zero em INT(5) Tipo: 00001, 00002 em vez de: 1, 2... fui pesquisar o manual do MySql, aí que descobri também.
Muito bom o artigo!!
Muito bom o artigo!!
15/05/2007 12:57pm
(~17 anos atrás)
Camarada, muito bom o seu artigo, eu confesso que não sabia disso assim como a maioria da galera...
04/05/2007 6:27am
(~17 anos atrás)