Re: RES: [firebase-br] Tipo de Campo (onde é feito o Trim??)

Carlos H. Cantu listas em warmboot.com.br
Qua Mar 9 16:24:59 -03 2005


Corrigindo, o Firebird 1.5 solucinou o problema do tráfego dos
varchars pela rede, desconsiderando os espaços do final do string. Vou
atualizar isso no referido artigo.

[]s
Cantu
http://www.warmboot.com.br
FireBase - http://www.FireBase.com.br

e> Não é tao simples assim. Quanto a maneira como estes dados trafegam até
e> o cliente, não há diferença entre um e outro. Ambos transitam com seu
e> tamanho definido.
e> O texto abaixo foi retirado do site da Firebase, mas já vi as mesmas
e> explicações em outros lugares.
e> Isto é importante quando estamos modelando, pois às vezes somos 
e> seduzidos a super dimensionar o tamanho de um campo achando que por ser
e> varchar não haverá prejuízo algum.
e> A BDE, por exemplo, não fazia distinção entre um e outro e retirava os
e> espaços do final de qualquer campo. O DBExpress não retira os espaços se
e> o campo for determinado como CHAR. Isto deve ocorrer em outros 
e> componentes de acesso, porém, independente do componente a comunicação
e> entre cliente e servidor será com o tamanho completo.

e> O link para o artigo é 
e> http://www.firebase.com.br/cgi-bin/firebase.cgi/artigo?ID=250
e> Abaixo, o trecho mais relevante a esta questão

e> "Diferenças entre CHAR e VARCHAR
e> Muitas pessoas pensam que é melhor utilizar um VARCHAR pois ele armazena
e> somente os dados (sem espaços no final), enquanto que o CHAR é 
e> armazenado em seu tamanho completo. Isso não é verdade. De fato, ambos
e> CHAR e VARCHAR são armazenados no buffer de memória com seu tamanho
e> completo (declarado no BD); quando o registro é armazenado no disco,
e> então o método de compressão RLE é usado para comprimir todo o registro,
e> ou seja : CHARs, VARCHARs, INTEGERs, DATEs, etc. todos juntos. Portanto,
e> se voce quer economizar espaço, os CHARs são um pouco melhor que os
e> VARCHARs (a diferença é que o VARCHAR armazena o tamanho do string em 2
e> bytes). Há também um bug conhecido que faz com que o VARCHAR não limpe o
e> "resto" do string quando voce altera o valor do mesmo para um string
e> menor do que o anterior, o que torna a compressão menos eficiente.

e> Muitas pessoas também acreditam que quando se é usado VARCHAR, apenas os
e> dados do string (sem os espaços em branco no final) são enviados pela
e> rede, enquanto que o CHAR seria enviado em seu tamanho total. Isso 
e> também não é verdade. A comunicação entre o cliente e o servidor é feita
e> via mensagens de tamanho fixo, portanto ambos CHAR e VARCHAR são 
e> enviados em seu tamanho total (declarado no BD).

e> Sendo assim, a decisão de que tipo usar deve se basear apenas nos 
e> requerimentos da aplicação. Por exemplo : Use CHARs para armazenar 
e> campos de tamanho fixo, use VARCHARs para armazenar dados de tamanho
e> variável (e permitir portanto uma correta concatenação se necessário)."






Mais detalhes sobre a lista de discussão lista