Tenho aqui um ambiente misto com algumas chaves primárias artificiais e outras naturais. Algumas das artificiais incluem "código interno do produto", "código do cliente" e "número do pedido", todas obtidas através de sequences.
Como o sistema é parcialmente replicado (ou parcialmente distribuído, depende do ponto de vista), muitas das chaves primárias são compostas, acrescentando o campo "código da empresa" para indicar a filial. Por exemplo: se um cliente é cadastrado na filial 3 ele pode ficar com o código 1275/3 enquanto um outro, cadastrado na matriz (que é mais antiga e portanto está com a sequence mais adiantada) fica com o código 45632/1. Da mesma forma, os pedidos da filial 7 são números baixos como 2349/7 enquanto na matriz já estão com 6 dígitos, por exemplo 170234/1. O código do cliente precisou ser uma chave artificial porque há casos de mais de um cliente com o mesmo CNPJ, em especial órgãos públicos. Por exemplo, todas as escolas costumam usar o mesmo CNPJ da Secretaria de Educação. Há casos em que o mesmo CNPJ aparece em 20 clientes diferentes. Isso traz um problema: apesar de haver uma replicação multi-master assíncrona entre as filiais e a matriz (desenvolvida internamente, usando topologia em estrela), as sequences ficam com valores diferentes. Não dá pra pegar o backup de uma empresa e colocar na outra sem rodar uma rotina para dar um "setval" nas sequences colocando o max(chave) em todas elas. Aproveito para perguntar: alguém tem uma sugestão para melhorar esta modelagem? Uma das premissas básicas é que uma loja não pode deixar de vender apenas porque a ADSL caiu (coisa que acontece toda semana). Nossa sincronização suporta estas falhas de forma transparente, apenas atrasando a replicação. A solução de conflitos é relativamente simples: em geral o UPDATE mais antigo vence e há detecção de edição simultânea de uma tupla no mesmo servidor através de timestamp. Em 27/03/08, Leandro DUTRA <[EMAIL PROTECTED]> escreveu: > > 2008/3/27, Evandro Ricardo Silvestre <[EMAIL PROTECTED]>: > > > Concordo com relação a chave composta perfeitamente boa, mas não > > concordo que criar uma chave primária quando se pode ter uma chave > > composta vai aumentar tanto assim eventos de E/S e gasto de > > armazenamento. > > > Não tem como dizer de antemão, tem de ser caso a caso. E foi isso que > questionei, dizer que sempre se cria uma chave artifical simples. > Pode ser neutro, valer a pena ou penalizar; em caso de ser neutro ou > penalizar, melhor ficar só com as naturais. > > -- Atenciosamente, Alexsander da Rosa Linux User #113925
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
