1. também usaria char(11) para o CPF: precisaria de uma forte motivação para usar bigint e com isso trocar 11 por 8 bytes no armazenamento...
2. formatação de valores é algo que o SGBD não deveria se preocupar, e se assim o fosse seria interessante criar uma função em SQL (ex: formatar_cpf()) como um wrapper usando o to_char() proposto pelo Osvaldo. 3. gostaria de lembrar que o paquiderme é o SGBD de código aberto mais avançado do mundo, e uma de suas grandes vantagens é a extensibilidade! Isto é, podemos criar um novo tipo de dados, o próprio *cpf*, implementá-lo em linguagem C e obter todas as suas vantagens, incluindo validação e formatação intrínsecas. Vide projeto isn<http://www.postgresql.org/docs/8.3/static/isn.html>do contrib. 4. o mesmo acima se aplica a um campo para armazenar CNPJ. 5. para RG a coisa fica mais complicada, pois o campo pode ser normalizado, além do que o seu número pode conter letras...! -- Rodrigo Hjort http://agajorte.blogspot.com 2010/11/8 Eduardo Az - EMBRASIS Informática e O&M <[email protected] > > ?Eu neste caso, acho melhor char(11) só cpf e char(14) cnpj ou cnpj junto > com cpf. > Minhas justificativas: > char porque: este campo não vai ser usado para calculos (tipo salarios, > vendas,etc) e o uso de qualuqer tipo de campo valor ao meu ver é mais > dispendioso para o banco de dados. > char em vez de varchar porque: melhora no desempenho, indexar com char > gera > uma resposta mais rápida que em varchar (verifiquei pessoalmente e também > via literatura sobre isto). > > Só não concordo com vc sobre o uso de varchar, pelo motivo citado acima. > > Eduardo Az > Dep.TI > EMBRASIS > +55(11)2122-0241 PABX > +55(11)8125-3845 TIM > +55(11)9826-0138 VIVO > [email protected] >
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
