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

[eduardo]

Obrigado Cantú

Carlos H. Cantu wrote:
> 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)."
> 
> 
> 
> ______________________________________________
> FireBase-BR (www.firebase.com.br) - Hospedado em www.bavs.com.br
> Para editar sua configuração na lista, use o endereço http://mail.firebase.com.br/mailman/listinfo/lista_firebase.com.br
>