2011/10/13 Shander Lyrio <[email protected]>: > > Examente por isto você pode sempre criar um índice unique na chave > natural que você usaria e que acha que garante unicidade. Teria o mesmo > efeito de garantir unicidade, e ainda facilitaria o uso do ORM. A que > custo?? Um pouco mais de espaço utilizado em disco.
Há outros custos. O cache fica mais sujo mais rápido, o modelo de dados fica mais opaco, a tentação de usar a chave artificial para todas as chaves estrangeiras aumenta e acaba‐se sendo forçado a fazer junções que seriam desnecessárias se as chaves estrangeiras fossem sobre as naturais. Sem contar que chaves naturais têm o potencial de satisfazer consultas com o índice implícito, sem precisar nem ir para a tabela; se a aplicação já usa as chaves naturais preferencialmente, isso tenderá a estar em memória também, com ganhos ainda melhores. > Eu acredito que o meio termo é, quase sempre, a melhor saída. Já vi > diversas discursões sobre isto aqui na lista e no final sempre chega-se > a conclusão que encontrar uma chave natural que realmente seja única é > tão difícil quando encontrar um gnomo no final do arco-íres. Não é verdade. Quem chega a essa conclusão é quem não entendeu o modelo de dados, e aí a modelagem e aplicação serão malfeitas, com as conseqüências de sempre para desempenho, documentação, consistência… _______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
