Eu tinha essa dúvida sempre, e de vez em quando eu esqueço e tenho que olhar de novo... eu sou assim, fazer o que!
De acordo do o site do MySQL, um campo do tipo CHAR vai de 0 a 255 com tamanho fixo, ou seja, se você declarar um campo como CHAR(30), ele vai guardar o que você escreveu (exemplo 'Daniel') e espaços em branco até completar os 30 bytes.
O VARCHAR é diferente. Até a versão 5.0, variava de 0 a 255, mas nas versões posteriores passou a aceitar até 65.535! E se você declarar um campo como VARCHAR(30) e escrever nele 'Daniel', ele vai ocupar somente 6 bytes.
Para ambos os tipos, se a string inserida for maior que o tamanho, o valor é truncado.
Por isso se você tem certeza do tamanho do campo, vale mais a pena usar o CHAR (CEP, telefone, sigla de UF etc), mas se você quer somente estipular um tamanho máximo, use VARCHAR (nome, logradouro, bairro etc).
Uma coisa interessante que eu nunca usei :) é a opção BINARY desses campos. CHAR BINARY e VARCHAR BINARY tornam esses campos sensitivos a maiúscula e minúscula, pois analisa o byte e não o caractere. Isso influencia na ordenação dos campos...
Abraço!
9 comentários:
bacana!
Legal!
Poxa rapaz...
Show de bola...
Nunca mais me esquecerei da dica...
Mas gostaria se caso você tiver uma outra oportunidade de esclarecer mais sobre este tal CHAR BINARY e VARCHAR BINARY, e se possível me avisasse em brunopib@gmail.com .
Novamente, muito obrigado.
o valor nem sempre é truncado, isso depende do SQL MODE, eu particularmente coloco uma configuração forte pois não quero que meus registros venham faltando, imagine a dor de cabeça que causaria se um valor monetário fosse truncado?
e também não concordo sobre "escolher o CHAR se você tem certeza do tamanho do campo", leva-se mais em consideração o (desempenho x espaço), muitas vezes prefiro setar campos como CHAR para uma melhor perfomance na recuperação dos dados.
E também eu não utilizaria um campo CHAR para um CEP, escolheria algum campo número (unsigned, zerofill) isso reduziria no mínimo uns 50% no armazenamento.
Eu tenho o costume de usar números somente para campos passíveis de cálculo, mas é interessante a utilização de um numérico com zerofill... eu nunca usei assim e vou experimentar. Quanto ao CHAR para tamanhos certos, há vários motivos sim, mas quando usamos campos principalmente pequenos com tamanho fixo, como UF, por exemplo, não penso 2 vezes para usar CHAR ao invés de VARCHAR. Desempenho está diretamente relacionado à estas definições, senão não haveria o porque existir CHAR; o tamanho fixo é uma "dica", se é que podemos definir assim.
Abraço e obrigado pelo comentário!
dei uma olhada no blog, tem muita coisa legal, vai pro meu favoritos!
;)
cool
Daniel
O Post é ótimo só precisa de um ajuste.
No caso do varchar ao inserir o valor "Daniel" o varchar usa 6 bytes para o valor e mais um byte para armazenar o tamanho totalizando 7 bytes.
Claro e objetivo! Obrigado!
Postar um comentário