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. Em 4 de março de 2010 15:24, Osvaldo Kussama <osvaldo.kuss...@gmail.com>escreveu: > Em 4 de março de 2010 13:28, Alexsander Rosa > <alexsander.r...@gmail.com> escreveu: > > > > Uma possibilidade é usar uma chave composta, tipo "CNPJ + chave extra" > onde > > esta chave extra tem NULL em todas as PF e quase todas as PJ. Quando uma > PJ > > pertencer a mais de um cliente (órgãos públicos, universidades, etc), > esta > > chave extra conterá um código (numérico? texto?) que identificará cada > > unidade. Para escolas, poderia ser um código tipo INEP, por exemplo. Em > > universidades poderia ser algum código que identifique o setor. > > > > Alguém tem alguma sugestão para isto? > > > Apenas uma observação: uma chave primária não pode conter NULL em > nenhum dos campos que a compõe. > Não ficou claro se quando você diz "chave composta" está ou não se > referindo a chave primária. > > Osvaldo > _______________________________________________ > pgbr-geral mailing list > pgbr-geral@listas.postgresql.org.br > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral > -- Atenciosamente, Alexsander da Rosa Linux User #113925 "Extremismo na defesa da liberdade não é defeito. Moderação na busca por justiça não é virtude." -- Barry Goldwater
_______________________________________________ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
