Re: [firebase-br]Numeric, BigIN =?ISO-8859-1?Q?T, _Char_ou_VarChar_para_armazen?= ar numero de 14 dígitos? Indices sobre expressões vale a pena?

Eduardo Jedliczka edujed em gmail.com
Qua Out 4 15:50:25 -03 2006


Se são 3 campos, eles devem ser armazenados de forma separada (pela
forma normal, respeitando a atomicidade da informação, e se desejável,
pode-se criar um campo calculado ou duplicado para obter o valor
total). Assim cria-se um único índice para os três (veja qual ordem
gera uma melhor seletividade).

Só uma coisa. BIGINT gera um número de 2^64 (o equivalente a 16 *
10^18) o que é mais que suficiente para armazenar 14 dígitos.

E sim, integer é mais rápido que char, que é mais rápido que varchar.

me lembro de ter respondido esta perngunta num prazo inferior a 30
dias. Talvez o autor dela não tenha visto minha resposta na época.

Abraço

Eduardo Jedliczka
Membro do TeamFB

Em 04/10/06, Henrique Netzka (Vetor
Sistemas)<henrique em vetorsistemas.com.br> escreveu:
> ahh, agora entendi a questão dos índices!!
>
> Bem, antes, sobre o desempenho do where... suponho que o BIGINT seja mais
> rápido do que um CHAR, na busca... Mas estou baseando isso na minha cabeça
> rs...
>
> Sobre os índices... Acho meio loucura criar um índice baseado em
> substrings!! Quem te responde de forma mais confiável creio ser o pessoal do
> TeamFB daqui da lista, mas eu criaria campos separados para a informação e
> índices sobre eles, lembrando que a ordem dos campos dentro de um índice
> influencia no ganho de performance do mesmo...
>
> Mas analise a freqüência de uso... Se você vai usar mais buscas por cada
> fragmento do que pelo campo inteiro, é melhor criar vários; se você for
> utilizar quase sempre a busca pelos 4 valores, porém eventualmente buscará
> por apenas um deles, um campo apenas poderá resolver; outra alternativa é
> usar a boa e velha de(s)normalização, e criar ambos: crie um campo com todas
> as informações e outros 4 com as informações desmembradas, e faça o banco
> alimentá-las automaticamente (uma trigger pegaria o valor do UM e
> fragmentaria, ou pegaria o dos QUATRO e desfragmentaria). A gravação ficará
> mais lenta, o banco um pouco maior, mas pode-se ter um bom ganho pra
> recuperar as informações de ambas as formas (valor inteiro e fragmentos dos
> valores).
>
> Ajudou?!
> Um abraço,
> Henrique
>
> ----- Original Message -----
> From: "Fernando Reis Guimarães" <fernandobhz em gmail.com>
> To: "FireBase" <lista em firebase.com.br>
> Sent: Wednesday, October 04, 2006 2:55 PM
> Subject: Re: [firebase-br]Numeric, BigINT, Char ou VarChar para armazenar
> numero de 14 dígitos? Indices sobre expressões vale a pena?
>
>
> Bom ajudou sim....
> Mas pensei mais na questão do desempenho para buscar quando for
> colocar um where nele.
>
> Outro ponto, preciso dessas informações fragmentadas.
> 14 digitos, sendo que do digito 1 ao 5 chamo-a de loccal
> de 6 a 8 rz,
> de 8 a 10 rt
> e de 10 a 14 conta.
>
> e preciso usar a rt, rt, loccal e conta em wheres.....
>
> Você acha que deverei criar outros campos para armazenar estes valores
> e criar indices sobre eles
>
> ou
>
> somente criar indices com expressao subtring(campo from 1 for 5)...
>
> Valew...
>
> Em 04/10/06, Henrique Netzka (Vetor
> Sistemas)<henrique em vetorsistemas.com.br> escreveu:
> > Fernando,
> >
> > "Tudo depende" rs... Algumas premissas tomo como verdade quando for
> > escolher
> > o campo:
> >
> > - VarChar é sempre uma opção ruim para campos com conteúdo de tamanho
> > fixo!
> > Não que seja ruim, mas é desnecessário! A manutenção de um varchar custa
> > mais para o banco do que de outros campos (char, por exemplo), pois o
> > banco
> > precisa calcular qual o tamanho do conteúdo e armazená-lo também.
> > - Um integer, por outro lado, tem 32 bits; ou seja, 4 bytes. 4 bytes não
> > te
> > darão 14 digitos numéricos. Restam então CHAR e BIGINT.
> > - Um campo CHAR de 14 posições teria 14 bytes; um campo BigINT possui 8;
> > sendo 8 bytes menos que 14, o seu banco inflaria menos se você utilizasse
> > os
> > campos como BigINT ao invés de CHAR; também, se o número não possuísse 14
> > dígitos (creio que não seja a situação, mas vai que aconteça) você não
> > precisará dar um TRIM para convertê-lo para Integer...
> >
> > Espero ter ajudado, e não ter falado nenhuma besteira! rs...
> >
> > Henrique
> >
> > ----- Original Message -----
> > From: "Fernando Reis Guimarães" <fernandobhz em gmail.com>
> > To: "FireBase" <lista em firebase.com.br>
> > Sent: Wednesday, October 04, 2006 1:46 PM
> > Subject: Re: [firebase-br]Numeric, BigINT, Char ou VarChar para armazenar
> > numero de 14 dígitos? Indices sobre expressões vale a pena?
> >
> >
> > .
> > .
> >
> > --
> > Atenciosamente;
> > Fernando.
> >
> > ______________________________________________
> > FireBase-BR (www.firebase.com.br) - Hospedado em www.locador.com.br
> > Para editar sua configuração na lista, use o endereço
> > http://mail.firebase.com.br/mailman/listinfo/lista_firebase.com.br
> > Para consultar mensagens antigas: http://firebase.com.br/pesquisa
> >
> >
> > ______________________________________________
> > FireBase-BR (www.firebase.com.br) - Hospedado em www.locador.com.br
> > Para editar sua configuração na lista, use o endereço
> > http://mail.firebase.com.br/mailman/listinfo/lista_firebase.com.br
> > Para consultar mensagens antigas: http://firebase.com.br/pesquisa
> >
>
>
> --
> Atenciosamente;
> Fernando.
>
> ______________________________________________
> FireBase-BR (www.firebase.com.br) - Hospedado em www.locador.com.br
> Para editar sua configuração na lista, use o endereço
> http://mail.firebase.com.br/mailman/listinfo/lista_firebase.com.br
> Para consultar mensagens antigas: http://firebase.com.br/pesquisa
>
>
> ______________________________________________
> FireBase-BR (www.firebase.com.br) - Hospedado em www.locador.com.br
> Para editar sua configuração na lista, use o endereço http://mail.firebase.com.br/mailman/listinfo/lista_firebase.com.br
> Para consultar mensagens antigas: http://firebase.com.br/pesquisa
>


-- 
[s]

==========================
Eduardo Jedliczka
Apucarana - Pr
==========================




Mais detalhes sobre a lista de discussão lista