Ops, então o elogio foi para o Sebastião.
Esse papo de chave artificial (surrogate) e chaves candidatas dá assunto para
300 dias :)
Eu nos meus 20 anos de profissão e de modelagem de dados já cheguei a conclusão
que uma chave candidata é igual a político. É só ela ser eleita que ela já
começa a mudar de opinião :)
O que eu quero dizer é que uma chave que hoje faz todo sentido de ser candidata
deixará de ser daqui a 5 anos, por conta das mudanças externas impostas pelo
ambiente. E quanto mais tempo ela tiver existido, maior será a dor de cabeça
será para ela ser mudada.
Se vc já modela todas (ou quase todas) as tabelas do sistema com surrogate
keys, vc evita uma gama enorme de problemas que surgirão, aumentando o ciclo de
vida do seu modelo, enfim fazendo que se gaste menos para implementar mudanças.
Se vc analisar os modelos do SAP R3, ou do Oracle Applications, vc verá que
eles são recheados de Surrogate keys. Só assim, eles conseguem responder por
uma gama enorme de requisitos que chegam a todo instante.
Sugiro que vc dê uma olhada no livro do Scott Ambler "Refactoring Databases" -
lá ele detalha em minúcias o que eu tentei explicar aqui.
Saudações,
Josir Gomes
Em Sex, 2007-08-10 às 10:00 -0300, Josir Gomes escreveu:
> legal vc ter levantado essa questão.
Desta vez eße mérito não foi meu, mas do Sebastião.
> E o que vc me diz de tabelas que representa um relacionamento n-n de 2
> tabelas que tenham chaves primárias surrogate?
Em primeiro lugar, eu questionaria o fato das chaves primárias das
tabelas interrelacionadas serem artificiais.
Em segundo lugar, eu buscaria usar chaves candidatas simples,
*principalmente* porque ißo me forçaria a declará-las ? e uma chave
primária artificial *nunca* deve substituir uma chave candidata, apenas
complementá-la *se* esta for composta ou tiver algum outro problema
_grave_
_______________________________________________
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
