> Não evita duplicidade? Me de um exemplo ou um case por favor, porque > > então a documentação está errada e tudo o que li tb. > > Sim, escreve-se muita bobagem. > > Por exemplo, imagine um cadastro qualquer, com um código incremental e > um nome que tem de ser único. É um exemplo simplérrimo, só para > mostrar o problema. > > 1 José > 2 José > 3 José > > > Bom dia,
Desculpa-me entrar nesta discussão, contudo neste exemplo mencionado há um possível erro de modelagem, o problema não é a chave artificial explicitamente. Chaves artificiais não são um mal por si só, mas também não salvam sempre a pátria. Temos de tomar cuidado para que não destruam uma modelagem. Concordo que chaves artificiais podem ser problema quando o modelo está errado, mas nem sempre chaves naturais são adequadas ou mesmo possuem bom desempenho (imagine uma chave composta onde todos os campos são strings, pode ser muito ruim para um bom desempenho de consultas). Além do mais, um id interno para o usuário, para a empresa, etc., pode ser facilmente entendido, não é um monstro que complica tudo. Óbvio que precisamos tomar cuidado e cada caso é um caso, há tabelas onde não temos necessidade alguma de criar chaves artificiais. (lembre-se que nem as regras de normalização sempre devem ser seguidas, há momentos em que precisamos ferir uma delas para que o desempenho não seja ínfimo). -- André de Camargo Fernandes
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
