Em 4 de março de 2010 16:00, Alexsander Rosa <[email protected]>escreveu:
> Sim, na verdade eu editei o texto várias vezes e este detalhe passou > despercebido. Este campo, "chave_extra", ficaria com um valor tipo 0 (se for > inteiro) ou brancos (se for texto) na maioria dos casos. Mas tenho minhas > dúvidas se esta é mesmo a melhor solução, acho que no fim vai ser melhor > usar uma chave artificial, a famosa "código do cliente". > > Existe também o problema da replicação. Cada filial tem um servidor > (replicado) e nenhuma loja pode parar por falta de Internet ou falta de > comunicação com a Matriz. Sei que muitas empresas simplesmente param quando > isso acontece, com a tradicional explicação de que "estamos sem sistema", > mas nós nunca achamos isto aceitável -- especialmente no caso das redes de > varejo. Além disso, a legislação praticamente exige que o software de PDV > emita cupons mesmo com o cabo de rede cortado. > > Neste cenário, cada servidor tem suas (poucas) SEQUENCES independentes > (estão fora da replicação) e as PK de algumas tabelas são chaves compostas > que incluem a coluna "id_servidor". Os clientes acabam recebendo um código > que costuma ser exibido no formato 9502/1 (código 9502 do servidor 1) e os > JOINS precisam sempre considerar isto. Não chega a ser nada desesperador, > mas nesta reforma vamos reduzir o uso de chaves artificiais ao mínimo > necessário -- como, talvez, esta tabela de "pessoas". > > Por enquanto, sem ter ainda me aprofundado nesta reforma (são centenas de > tabelas), acho difícil escapar de pelo menos três chaves artificiais: código > da pessoa, código do produto e número do pedido. > > Às vezes, o que parece ser uma chave artificial acaba recebendo um significado no negócio e, por isso, toma enlaces de chave natural. Por exemplo, quanto temos um número do pedido, esse número é o que identifica o mesmo, é usado pelo comprador ao se referir sobre seu pedido, vai para uma nota fiscal, então ele possui significado, deixa de ser uma chave artificial, no sentido restrito. Abraços, -- André de Camargo Fernandes
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
