2011/10/14 Alexsander Rosa <alexsander.r...@gmail.com> > Em 13 de outubro de 2011 18:43, <desenvolvedor....@gmail.com> escreveu: > > Alexandre, poderia citar os malefícios das chaves artificiais? > > > > Supondo que você esteja se referindo a mim (Alexsander), o problema é > o uso indiscriminado de chaves artificiais. Por exemplo, uma tabela de > CEP não precisa ter uma coluna "id_cep" como PK, o próprio CEP é uma > PK melhor. Neste caso, para saber o CEP de um logradouro é preciso um > JOIN a mais. Outro exemplo: porque usar "id_sexo numeric" se podemos > usar simplesmente "sexo char(1)" com um CHECK para garantir que seja > "M" ou "F"? Muita gente usa ID em toda a base, de ponta a ponta, e > isso é ruim. > > -- > Atenciosamente, > Alexsander da Rosa > http://rednaxel.com > _______________________________________________ > pgbr-geral mailing list > pgbr-geral@listas.postgresql.org.br > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral >
Voce citou um bom exemplo, no caso de CEP "cidade" onde o cep pode repetir até 2 vezes ou mais. Exemplo: Rua Pio XII Centro Mairiporã SP 07600000 Rua XV de Novembro Centro Mairiporã SP 07600000 Vou cirar um outro exemplo calssico, Nota Fiscal, qdo a NF chegar a 999.999 ela volta ao 1 e muda a série, quem coloca NF como PK ja esta cometendo um erro, o ideal seria NF+DataEmissão ou NF+Serie Na minha opnião tem que ter muito cuidado com relação a chaves etc.
_______________________________________________ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
