Em 15/10/08, Fábio Telles Rodriguez<[EMAIL PROTECTED]> escreveu:
> 2008/10/15 Junin <[EMAIL PROTECTED]>
>
>> Fábio,
>>
>> Vc tem razão, é gosto de detalhes. Mas dando enfâse ao foco principal,
>> chave "burra" ou chave natural?
>>
>
> Para mim isso depende da regra de negócio....
>
> 1º) Uma chave natural, se não for a PK, deve ao menos ser a UK
> 2º) Se a aplicação permite com frequência a alteração da PK, talvez uma
> chave artificial dê menos problema com processos de "de para" nas tabelas
> relacionadas. O PostgreSQL felizmente permite a atualização automática com
> um tipo de FK mais inteligente. Então isso não costuma ser um bom argumento;
> 3º) Se você tem uma chave natural composta enorme, com vários campos, uma
> chave artificial pode ajudar em alguns casos.
> 4º) Cada caso é um caso.
>
> Nunca me atrevi a escrever sobre isso, mas a minha prática gira em torno
> destas 4 regras.
>
Siga os conselhos do Fabio Telles.
Tem uma coisa que não entendo:
CREATE DOMAIN CEP AS TEXT CHECK (VALUE ~
'^([0-9]{2})[.]([0-9]{3})[-]([0-9]{3})$' ) ;
CEP não é um número (de 8 algarismos)? Por quê considerá-lo como texto?
Não é melhor que ele seja, por exemplo, um integer?
Se você deseja apresentá-lo com pontos e traços faça-o apenas no
momento da exibição. Não existe o menor sentido em armazená-lo com
estes separadores.
Lembre-se: formato de armazenamento é diferente de formato de exibição.
Osvaldo
_______________________________________________
pgbr-geral mailing list
[email protected]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
