> Como o SQL não implementa chaves artificiais de verdade, até porque > não separa o modelo lógico do físico, e como o suporte à abstração de > chaves compostas é extremamente deficiente ou, até, inexistente em boa > parte das linguagens de programação, acaba-se usando chave artificial > quando a natural é composta de, digamos, mais de três atributos, > conforme o gosto do freguês. > uma "boa" implementação de chaves compostas pode ser um objeto, por exemplo, chamado idAlgumaCoisa contendo os atributos referentes à chave natural? > Outro uso de chaves artificiais é quando nenhuma natural é estável, e > o SGBD não suporta ON UPDATE CASCADE, mas eu, particularmente, prefiro > alterações explícitas das chaves. > o custo computacional de um ON UPDATE CASCADE vale o seu uso em tabelas gigantes? Concordamos que cpf e cnpj são boas chaves naturais candidatas mas e para o caso de uma tabela em que só tenha um atributo, como existe muito, uma tabela cargo relacionando com funcionário e nesta tabela cargo só se tem o nome do cargo. Minha pergunta é, seria melhor forçar o dono do sistema fazer uma codificação para cada cargo, tipo, A-1 : Gerente ou A-2 : Arquiteto ou mesmo utilizar a famigerada chave artificial? Neste último caso a chave artificial fica a cargo de uma sequence que fica a cargo do banco... e da preguiça do analista que implementar isso. > Finalmente, há quem use chaves artificiais quando tem necessidades > muito específicas de desempenho extremo, mas a maior parte das vezes > elas impõem penalidades por aumentar os eventos de E/S ou por não > garantirem unicidade. > > O que não se pode jamais fazer é definir apenas a chave artificial, e > não a(s) natural(is). > Com este comentário, acabo achando que a criação de códigos para uma chave natural para uma determinada tabela como exemplo a tabela cargo acima é válido.
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
