Re: [pgbr-geral] Usando CPF/CNPJ como PK
Em Sáb 06 Mar 2010, às 22:29:33, Leandro DUTRA escreveu: Olha, acho que minha cabeça está ruim… quando você diz que CPF e CNPJ são boas chaves candidatas, eu disse que não necessariamente. Nem sempre são chaves, certo? Há (ou havia) mulheres casadas sem CPF, há estabelecimentos com um CNPJ para vários endereços… Aliás, toda chave candidata é uma chave natural. A chave artificial é justamente a que foi acrescentada às naturais. Talvez esteja havendo confusão entre chave candidata e atributo candidato a chave? É uma das razões pelas quais não gosto da expressão chave candidata, que na verdade é apenas um resquício de quando se achava que era necessário designar uma chave como a primária. Só para lembrar, chaves candidatas são as chaves alternativas mais a primária. Qual o problema do nome do cargo ser chave? Para quê esse código? Mas ai eu ficaria duplicando informação. E para isso existiriam as chaves artificiais, não? Não entendi. Se o nome do cargo é único (geralmente é), já evita duplicação, e o código seria redundante. E chave artificial não evita duplicação — na verdade, está mais para OID que para chave. isso é verdade, geralmente o cargo já é único. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Usando CPF/CNPJ como PK
2010/3/7 Flávio Alves Granato digitaldr...@gmail.com: isso é verdade, geralmente o cargo já é único. Exato, e esse é, por definição, uma chave natural: algo que não se quer que se repita. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (11) 3854 7191 gTalk: xmpp:leand...@jabber.org +55 (11) 9406 7191ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT-3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Usando CPF/CNPJ como PK
Em Sex 05 Mar 2010, às 21:05:37, Leandro DUTRA escreveu: 2010/3/5 Flávio Alves Granato digitaldr...@gmail.com: uma boa implementação de chaves compostas pode ser um objeto, por exemplo, chamado idAlgumaCoisa contendo os atributos referentes à chave natural? Por aí, é como se faz em COBOL. o custo computacional de um ON UPDATE CASCADE vale o seu uso em tabelas gigantes? Qual custo? Afinal, nenhuma chave é alterada constantemente. Concordo. E esse custo amiúde é compensado por evitar junções devido ao uso de chaves artificiais, pela economia do índice associado, pelo ‘emagrecimento’ das tabelas… Concordamos que cpf e cnpj são boas chaves naturais candidatas Não necessariamente. por isso eu disse boa. 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 Não entendi. Qual o problema do nome do cargo ser chave? Para quê esse código? Mas ai eu ficaria duplicando informação. E para isso existiriam as chaves artificiais, não? 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. Não entendi mesmo. o mesmo acima. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Usando CPF/CNPJ como PK
2010/3/6 Flávio Alves Granato digitaldr...@gmail.com: Concordamos que cpf e cnpj são boas chaves naturais candidatas Não necessariamente. por isso eu disse boa. Olha, acho que minha cabeça está ruim… quando você diz que CPF e CNPJ são boas chaves candidatas, eu disse que não necessariamente. Nem sempre são chaves, certo? Há (ou havia) mulheres casadas sem CPF, há estabelecimentos com um CNPJ para vários endereços… Aliás, toda chave candidata é uma chave natural. A chave artificial é justamente a que foi acrescentada às naturais. Talvez esteja havendo confusão entre chave candidata e atributo candidato a chave? É uma das razões pelas quais não gosto da expressão chave candidata, que na verdade é apenas um resquício de quando se achava que era necessário designar uma chave como a primária. Só para lembrar, chaves candidatas são as chaves alternativas mais a primária. Qual o problema do nome do cargo ser chave? Para quê esse código? Mas ai eu ficaria duplicando informação. E para isso existiriam as chaves artificiais, não? Não entendi. Se o nome do cargo é único (geralmente é), já evita duplicação, e o código seria redundante. E chave artificial não evita duplicação — na verdade, está mais para OID que para chave. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (11) 3854 7191 gTalk: xmpp:leand...@jabber.org +55 (11) 9406 7191ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT-3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Usando CPF/CNPJ como PK
Em 4 de março de 2010 17:40, Leandro DUTRA leandro.gfc.du...@gmail.comescreveu: 2010/3/4 Alexsander Rosa alexsander.r...@gmail.com: Podem me chamar de ultrapassado, mas nunca simpatizei com UUIDs. Mór di quê? Acho que as desvantagens superam as vantagens. -- 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
Re: [pgbr-geral] Usando CPF/CNPJ como PK
Em 5 de março de 2010 09:30, Alexsander Rosa alexsander.r...@gmail.com escreveu: Em 4 de março de 2010 17:40, Leandro DUTRA leandro.gfc.du...@gmail.com escreveu: 2010/3/4 Alexsander Rosa alexsander.r...@gmail.com: Podem me chamar de ultrapassado, mas nunca simpatizei com UUIDs. Mór di quê? Acho que as desvantagens superam as vantagens. Em sua opinião quais seriam? -- Dickson S. Guedes mail/xmpp: gue...@guedesoft.net - skype: guediz http://guedesoft.net - http://www.postgresql.org.br ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Usando CPF/CNPJ como PK
Pra mim a única vantagem é poder gerar UUID fora do banco sem risco significativo de colisão. Aliás, o fato de não haver 100% de garantia de que não haverá JAMAIS uma colisão no longo prazo (imagine dezenas de anos em centenas de filiais com milhares de transações por segundo) é uma desvantagem. Qualquer probabilidade maior que 0% pode sempre acontecer -- e Murphy nos garante que VAI acontecer. E o pior: quando houver uma colisão, se o UUID não for UNIQUE ninguém ficará sabendo... Outras desvantagens: - dificulta o DEBUG (e eventuais auditorias), Imagine ativar o log_statement = mod e acompanhar o resultado. Imagine tentar rastrear o que um determinado usuário fez num dia e hora específicos olhando os SQL que ele gerou no período. Sabemos que pode-se modelar a auditoria, mas os negócios evoluem e o que se quer monitorar hoje é diferente do que se monitorava ontem. Arquivar o SQL é uma garantia de poder buscar coisas do passado, quando não se gravava a trilha de auditoria que se grava hoje. - ocupa BEM mais espaço em disco/memória que integer Uma UUID ocupa 128 bits. Um inteiro ocupa 32 bits. Em alguns casos pode-se usar até smallint, que ocupa 16 bits. Numa tabela que represente um relacionamento N x N com apenas duas colunas, pode-se ter um pulo de 4 (dois smallint) para 32 bytes (dois UUID) por tupla. Os índices também sofrem um impacto significativo. Nunca gostei do argumento memória é barata. - não pode ser usada em comunicação verbal. Imagine uma atendente de call center passando uma UUID para o cliente anotar como número da transação. Se eu tiver que usar uma sequence pra gerar este número da transação, o uso de UUID perde todo o sentido. Em 5 de março de 2010 10:17, Dickson S. Guedes lis...@guedesoft.netescreveu: Em 5 de março de 2010 09:30, Alexsander Rosa alexsander.r...@gmail.com escreveu: Em 4 de março de 2010 17:40, Leandro DUTRA leandro.gfc.du...@gmail.com escreveu: 2010/3/4 Alexsander Rosa alexsander.r...@gmail.com: Podem me chamar de ultrapassado, mas nunca simpatizei com UUIDs. Mór di quê? Acho que as desvantagens superam as vantagens. Em sua opinião quais seriam? -- Dickson S. Guedes mail/xmpp: gue...@guedesoft.net - skype: guediz http://guedesoft.net - http://www.postgresql.org.br ___ 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
Re: [pgbr-geral] Usando CPF/CNPJ como PK
2010/3/5 Alexsander Rosa alexsander.r...@gmail.com: - não pode ser usada em comunicação verbal. Imagine uma atendente de call center passando uma UUID para o cliente anotar como número da transação. Se eu tiver que usar uma sequence pra gerar este número da transação, o uso de UUID perde todo o sentido. Detalhe: uma chave artificial, em princípio, torna-se natural quando chega ao usuário. Não precisa nem passar para o cliente: se a aplicação a usa na lógica, e a mostra para um operador como a atendente, já virou uma chave natural redundante com a chave natural preexistente. Idealmente, a aplicação nem a veria, mas creio não ser possível no SQL. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (11) 3854 7191 gTalk: xmpp:leand...@jabber.org +55 (11) 9406 7191ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT-3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Usando CPF/CNPJ como PK
Dickson, Em 4 de março de 2010 20:13, Mozart Hasse mozart.ha...@usa.net escreveu: Ah, questão de prática. -... cuidar dos malditos 40% sem PK artificial em bases muito menores. ... Mozart, apenas por curiosidade, essas chaves artificiais são sequences? Não, normalmente são apenas registros numerados pela aplicação via código ou triggers. Se sim, já aconteceu de você precisar copiar dados de outras bases para esta por exemplo? Se sim, pode nos expor como você o fez? Replicação. No caso de inserções em servidores distintos minha aplicação tem um esquema de alocação e distribuição automática de faixas de códigos entre eles, de forma que dois servidores nunca usam o mesmo código ao inserir dados em bases diferentes na mesma tabela. Quando a replicação não resolve, eu renumero os registros de uma das bases sem dó, incluindo todas as FKs dependentes da tabela principal. Não dá tanto trabalho assim, basta uns INSERT INTO SELECT bem escolhidos, como eu disse é questão de prática. Normalmente só precisamos renumerar alguma coisa na hora de exportar ou importar dados de sistemas externos. Não consigo lembrar de uma PK mal escolhida que nos tenha obrigado a renumerar alguma coisa por conta de migração ou conversão de dados. Já o abismo entre a perfeição conceitual de uma chave natural e o uso dela pela #(-)*%$#**$ do otimizador SQL não tem solução nem gambiarra que melhore. Atenciosamente Mozart Hasse ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Usando CPF/CNPJ como PK
2010/3/5 Mozart Hasse mozart.ha...@usa.net: Mozart, apenas por curiosidade, essas chaves artificiais são sequences? Não, normalmente são apenas registros numerados pela aplicação via código ou triggers. Ah, agora entendo porque tens tantos problemas. Já o abismo entre a perfeição conceitual de uma chave natural e o uso dela pela #(-)*%$#**$ do otimizador SQL não tem solução nem gambiarra que melhore. Na verdade há dois abismos: entre o modelo relacional e outros conceitos associados, como o próprio original de chave artificial, de um lado, e de outro o SQL; e entre as boas práticas de programação e os programas que geralmente se fazem. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (11) 3854 7191 gTalk: xmpp:leand...@jabber.org +55 (11) 9406 7191ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT-3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Usando CPF/CNPJ como PK
Em 05/03/2010 13:22, Leandro DUTRA escreveu: Já o abismo entre a perfeição conceitual de uma chave natural e o uso dela pela #(-)*%$#**$ do otimizador SQL não tem solução nem gambiarra que melhore. Na verdade há dois abismos: entre o modelo relacional e outros conceitos associados, como o próprio original de chave artificial, de um lado, e de outro o SQL; e entre as boas práticas de programação e os programas que geralmente se fazem. Não sei se é uma outra thread, mas eu gostaria de saber mais sobre chaver atificial, tipo quando é indicado para eu utilizar, assim pelo menos não utilizarei a torto e direito. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Usando CPF/CNPJ como PK
2010/3/5 Flávio Alves Granato digitaldr...@gmail.com: Não sei se é uma outra thread, mas eu gostaria de saber mais sobre chaver atificial, tipo quando é indicado para eu utilizar, assim pelo menos não utilizarei a torto e direito. Hm, vale um blogue. Para resumir, originalmente era para só o DBA ver chaves artificiais, no modelo físico. No modelo lógico, que deveria ser o único visível para usuários, aplicativos e ADs, apareceriam só as chaves naturais. Seria uma mera questão de desempenho; mesmo a pretensa complexidade das chaves compostas deveria ser abstraída pelas linguagens de programação, como aliás fazíamos em COBOL. 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. 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. 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). -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (11) 3854 7191 gTalk: xmpp:leand...@jabber.org +55 (11) 9406 7191ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT-3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Usando CPF/CNPJ como PK
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 pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Usando CPF/CNPJ como PK
2010/3/5 Flávio Alves Granato digitaldr...@gmail.com: uma boa implementação de chaves compostas pode ser um objeto, por exemplo, chamado idAlgumaCoisa contendo os atributos referentes à chave natural? Por aí, é como se faz em COBOL. o custo computacional de um ON UPDATE CASCADE vale o seu uso em tabelas gigantes? Qual custo? Afinal, nenhuma chave é alterada constantemente. E esse custo amiúde é compensado por evitar junções devido ao uso de chaves artificiais, pela economia do índice associado, pelo ‘emagrecimento’ das tabelas… Concordamos que cpf e cnpj são boas chaves naturais candidatas Não necessariamente. 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 Não entendi. Qual o problema do nome do cargo ser chave? Para quê esse código? 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. Não entendi mesmo. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (11) 3854 7191 gTalk: xmpp:leand...@jabber.org +55 (11) 9406 7191ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT-3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Usando CPF/CNPJ como PK
Estou prestes a fazer uma reforma no meu ERP e uma das coisas que está me incomodando é o cadastro de pessoas. Não pude usar CPF/CNPJ como chave primária natural porque, conforme já foi dito aqui várias vezes, muitos clientes diferentes usam o mesmo CNPJ, especialmente órgãos públicos. Para dar um exemplo: temos um cliente que tem várias CENTENAS de clientes -- a imensa maioria, escolas da rede estadual -- com o mesmo CNPJ (92.941.681/0001-00), que segundo a Receita Federal está registrado em nome da Secretaria da Educação do RS. 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? -- 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
Re: [pgbr-geral] Usando CPF/CNPJ como PK
Sugiro que se necessario adicione as primeiras posições antes do CNPJ o codigo do estado (De acordo com o IBGE) e o codigo do municipio (de acordo com o IBGE) talvez consiga algo mesclando essas informações com o CNPJ. at Em 4 de março de 2010 13:28, Alexsander Rosa alexsander.r...@gmail.com escreveu: Estou prestes a fazer uma reforma no meu ERP e uma das coisas que está me incomodando é o cadastro de pessoas. Não pude usar CPF/CNPJ como chave primária natural porque, conforme já foi dito aqui várias vezes, muitos clientes diferentes usam o mesmo CNPJ, especialmente órgãos públicos. Para dar um exemplo: temos um cliente que tem várias CENTENAS de clientes -- a imensa maioria, escolas da rede estadual -- com o mesmo CNPJ (92.941.681/0001-00), que segundo a Receita Federal está registrado em nome da Secretaria da Educação do RS. 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? -- 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 -- Atenciosamente Joares Luís Dalorsoleta Esta mensagem (incluíndo qualquer anexo) é dirigida apenas para o uso do indivíduo ou da entidade a qual está endereçada e pode conter informações privadas, proprietárias, privilegiadas, confidenciais que podem servir como evidências sob as leis aplicáveis ou em processos judiciais. Caso você não seja o destinatário pretendido, você está aqui notificado que qualquer uso, disseminação, distribuição, ou cópia dessa comunicação é estritamente proibida. Se você recebeu essa comunicação por engano, notifique-nos imediatamente por telefone, e (i) destrua essa mensagem se for um facsimile ou (ii) exclua imediatamente essa mensagem se esta for uma comunicação eletrônica. Obrigado. This message (including any attachments) is intended only for the use of the individual or entity to which it is addressed and may contain information that is non-public, proprietary, privileged, confidential, and exempt from disclosure under applicable law or may constitute as attorney work product. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, notify us immediately by telephone and (i) destroy this message if a facsimile or (ii) delete this message immediately if this is an electronic communication. Thank you. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Usando CPF/CNPJ como PK
Use uma pk artificial e seja feliz. Fuja de pks compostas, elas ainda vao te dar uma bela dor de cabeca. Abraco Joares Luis Dalorsoleta joa...@speedlinux.com.br escreveu: Sugiro que se necessario adicione as primeiras posições antes do CNPJ o codigo do estado (De acordo com o IBGE) e o codigo do municipio (de acordo com o IBGE) talvez consiga algo mesclando essas informações com o CNPJ. at Em 4 de março de 2010 13:28, Alexsander Rosa alexsander.r...@gmail.com escreveu: Estou prestes a fazer uma reforma no meu ERP e uma das coisas que está me incomodando é o cadastro de pessoas. Não pude usar CPF/CNPJ como chave primária natural porque, conforme já foi dito aqui várias vezes, muitos clientes diferentes usam o mesmo CNPJ, especialmente órgãos públicos. Para dar um exemplo: temos um cliente que tem várias CENTENAS de clientes -- a imensa maioria, escolas da rede estadual -- com o mesmo CNPJ (92.941.681/0001-00), que segundo a Receita Federal está registrado em nome da Secretaria da Educação do RS. 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? -- 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 -- Atenciosamente Joares Luís Dalorsoleta Esta mensagem (incluíndo qualquer anexo) é dirigida apenas para o uso do indivíduo ou da entidade a qual está endereçada e pode conter informações privadas, proprietárias, privilegiadas, confidenciais que podem servir como evidências sob as leis aplicáveis ou em processos judiciais. Caso você não seja o destinatário pretendido, você está aqui notificado que qualquer uso, disseminação, distribuição, ou cópia dessa comunicação é estritamente proibida. Se você recebeu essa comunicação por engano, notifique-nos imediatamente por telefone, e (i) destrua essa mensagem se for um facsimile ou (ii) exclua imediatamente essa mensagem se esta for uma comunicação eletrônica. Obrigado. This message (including any attachments) is intended only for the use of the individual or entity to which it is addressed and may contain information that is non-public, proprietary, privileged, confidential, and exempt from disclosure under applicable law or may constitute as attorney work product. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, notify us immediately by telephone and (i) destroy this message if a facsimile or (ii) delete this message immediately if this is an electronic communication. Thank you. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Usando CPF/CNPJ como PK
Concordo com o Fabiano. 2010/3/4 Wolak Sistemas - Fabiano Machado Dias fabi...@wolaksistemas.com.br Use uma pk artificial e seja feliz. Fuja de pks compostas, elas ainda vao te dar uma bela dor de cabeca. Abraco Joares Luis Dalorsoleta joa...@speedlinux.com.br escreveu: Sugiro que se necessario adicione as primeiras posições antes do CNPJ o codigo do estado (De acordo com o IBGE) e o codigo do municipio (de acordo com o IBGE) talvez consiga algo mesclando essas informações com o CNPJ. at Em 4 de março de 2010 13:28, Alexsander Rosa alexsander.r...@gmail.com escreveu: Estou prestes a fazer uma reforma no meu ERP e uma das coisas que está me incomodando é o cadastro de pessoas. Não pude usar CPF/CNPJ como chave primária natural porque, conforme já foi dito aqui várias vezes, muitos clientes diferentes usam o mesmo CNPJ, especialmente órgãos públicos. Para dar um exemplo: temos um cliente que tem várias CENTENAS de clientes -- a imensa maioria, escolas da rede estadual -- com o mesmo CNPJ (92.941.681/0001-00), que segundo a Receita Federal está registrado em nome da Secretaria da Educação do RS. 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? -- 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 -- Atenciosamente Joares Luís Dalorsoleta Esta mensagem (incluíndo qualquer anexo) é dirigida apenas para o uso do indivíduo ou da entidade a qual está endereçada e pode conter informações privadas, proprietárias, privilegiadas, confidenciais que podem servir como evidências sob as leis aplicáveis ou em processos judiciais. Caso você não seja o destinatário pretendido, você está aqui notificado que qualquer uso, disseminação, distribuição, ou cópia dessa comunicação é estritamente proibida. Se você recebeu essa comunicação por engano, notifique-nos imediatamente por telefone, e (i) destrua essa mensagem se for um facsimile ou (ii) exclua imediatamente essa mensagem se esta for uma comunicação eletrônica. Obrigado. This message (including any attachments) is intended only for the use of the individual or entity to which it is addressed and may contain information that is non-public, proprietary, privileged, confidential, and exempt from disclosure under applicable law or may constitute as attorney work product. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, notify us immediately by telephone and (i) destroy this message if a facsimile or (ii) delete this message immediately if this is an electronic communication. Thank you. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral -- Heraldo Borges https://sites.google.com/site/heraldoborges Delegado Estudantil - Sociedade Brasileira de Computação Linux User #504158 (http://counter.li.org) Celular : +55 21 84595844 Skype : heraldoborges E-mail : heraldobor...@gmail.com MSN: heraldobor...@hotmail.com Deus é o grande geômetra. Deus geometriza sem cessar. (Platão) ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Usando CPF/CNPJ como PK
Em 4 de março de 2010 14:04, HERALDO BORGES heraldobor...@gmail.comescreveu: Concordo com o Fabiano. +1 por chave artificial... -- Fabrízio de Royes Mello Blog sobre TI: http://fabriziomello.blogspot.com ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Usando CPF/CNPJ como PK
2010/3/4 Wolak Sistemas - Fabiano Machado Dias Use uma pk artificial e seja feliz. Fuja de pks compostas, elas ainda vao te dar uma bela dor de cabeca. Em 4 de março de 2010 14:04, HERALDO BORGES heraldobor...@gmail.com escreveu: Concordo com o Fabiano. Vocês já precisaram mesclar umas 5 bases, cada uma com uns 150 GB de dados, aproximadamente 800 tabelas, com 90% delas contendo chaves artificiais? Isso sim que é dor de cabeça. Procurem evitar chaves artificiais, mas se não tiver jeito usem-nas. Mas evite-as. []s Dickson S. Guedes mail/xmpp: gue...@guedesoft.net - skype: guediz http://guedesoft.net - http://www.postgresql.org.br ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Usando CPF/CNPJ como PK
Vocês já precisaram mesclar umas 5 bases, cada uma com uns 150 GB de dados, aproximadamente 800 tabelas, com 90% delas contendo chaves artificiais? Isso sim que é dor de cabeça. Procurem evitar chaves artificiais, mas se não tiver jeito usem-nas. Mas evite-as. Sim, chaves artificiais podem ser um problema se forem abusadas. Há casos não muito comuns nos quais são úteis ou mesmo necessárias, mas evite usar excessivamente, conforme disse sr. Dickson. Complementando, chaves compostas não são necessariamente problemas, desde que sejam naturais e obedeçam as exigências para serem chaves primárias. Tomem cuidado com o medo excessivo de de chaves compostas, tenham medo mesmo de muitas chaves artificiais. -- André de Camargo Fernandes ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Usando CPF/CNPJ como PK
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
Re: [pgbr-geral] Usando CPF/CNPJ como PK
2010/3/4 Joares Luis Dalorsoleta joa...@speedlinux.com.br: Sugiro que se necessario adicione as primeiras posições antes do CNPJ o codigo do estado (De acordo com o IBGE) e o codigo do municipio (de acordo com o IBGE) talvez consiga algo mesclando essas informações com o CNPJ. Não, isso seria confuso e furado. Informações diferentes têm de ficar em atributos diferentes, sob pena de tornar a aplicação mais complexa e a base, mais difícil de entender. Além disso, as adições sugeridas não garantiriam unicidade. Uma solução seria uma entidade filha da pessoa jurídica, e essa teria uma chave composta do CNPJ com algum outro identificador natural, como nome da escola, ou endereço. Assim as consultas na tabela principal não seriam prejudicadas. Para evitar causar problemas, apenas os tipos de cliente relevantes poderiam entrar nessa tabela filha. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (11) 3854 7191 gTalk: xmpp:leand...@jabber.org +55 (11) 9406 7191ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT-3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Usando CPF/CNPJ como PK
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.comescreveu: 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
Re: [pgbr-geral] Usando CPF/CNPJ como PK
Em 4 de março de 2010 16:00, Alexsander Rosa alexsander.r...@gmail.comescreveu: 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 pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Usando CPF/CNPJ como PK
Em 4 de março de 2010 16:00, Alexsander Rosa alexsander.r...@gmail.com escreveu: 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 Talvez seja melhor pensar em UUIDs. http://en.wikipedia.org/wiki/Universally_Unique_Identifier -- Tarcisio F. Sassara ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Usando CPF/CNPJ como PK
Leandro: Em 4 de março de 2010 16:30, Leandro DUTRA leandro.gfc.du...@gmail.comescreveu: 2010/3/4 Alexsander Rosa alexsander.r...@gmail.com: 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) Essa informação depois é replicada para outros servidores? Sim, tudo é replicado para todos os servidores (exceto as sequences). Provavelmente existem pessoas 9502/2, 9502/16, 9502/101, etc criadas em momentos bem diferentes, de acordo com as datas de inauguração de cada filial. Números baixos costumam aparecer dezenas de vezes, um para cada filial. Por outro lado, números mais altos geralmente só aparecem nas lojas mais antigas. Lembrando que muitas vezes nós somos o ENÉSIMO sistema implantado e acabamos herdando cadastros com milhares de clientes e, sempre que possível, mantemos os códigos. Em geral, se não houver como identificar as lojas no sistema legado, colocamos todos os cadastros importados como se tivessem sido criados na Matriz, que quase sempre é o servidor com ID 1. -- 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
Re: [pgbr-geral] Usando CPF/CNPJ como PK
Podem me chamar de ultrapassado, mas nunca simpatizei com UUIDs. Em 4 de março de 2010 16:43, Tarcísio Sassara sassara.tarci...@gmail.comescreveu: Em 4 de março de 2010 16:00, Alexsander Rosa alexsander.r...@gmail.com escreveu: 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 Talvez seja melhor pensar em UUIDs. http://en.wikipedia.org/wiki/Universally_Unique_Identifier -- Tarcisio F. Sassara -- 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
Re: [pgbr-geral] Usando CPF/CNPJ como PK
2010/3/4 Alexsander Rosa alexsander.r...@gmail.com: Podem me chamar de ultrapassado, mas nunca simpatizei com UUIDs. Mór di quê? -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (11) 3854 7191 gTalk: xmpp:leand...@jabber.org +55 (11) 9406 7191ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT-3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Usando CPF/CNPJ como PK
Em 4 de março de 2010 16:53, Alexsander Rosa alexsander.r...@gmail.com escreveu: Sim, tudo é replicado para todos os servidores (exceto as sequences). Provavelmente existem pessoas 9502/2, 9502/16, 9502/101... Não detona relatórios essas duplicidades? Relatórios do tipo Ranking podem mostrar resultados bem diferentes do real. -- Tarcisio F. Sassara ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Usando CPF/CNPJ como PK
+1 (Falou e disse!) From: Wolak Sistemas - Fabiano Machado Dias fabi...@wolaksistemas.com.br Subject: Re: [pgbr-geral] Usando CPF/CNPJ como PK Use uma pk artificial e seja feliz. Fuja de pks compostas, elas ainda vao te dar uma bela dor de cabeca. Abraco ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Usando CPF/CNPJ como PK
Ah, questão de prática. Tenho 900 tabelas para brincar e de proporção deve dar uns 60% com PK artifical contra 40% sem. Realmente base com 150GB eu não tenho, mas no meu caso a dor de cabeça é cuidar dos malditos 40% sem PK artificial em bases muito menores. Atenciosamente, Mozart Hasse From: Dickson S. Guedes lis...@guedesoft.net Subject: Re: [pgbr-geral] Usando CPF/CNPJ como PK Vocês já precisaram mesclar umas 5 bases, cada uma com uns 150 GB de dados, aproximadamente 800 tabelas, com 90% delas contendo chaves artificiais? Isso sim que é dor de cabeça. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Usando CPF/CNPJ como PK
Claro que não detona, são meras chaves compostas -- e com apenas DUAS colunas. Um exemplo pior de chave composta é o da tabela dos cupons fiscais, cuja PK tem quatro colunas (data, nº do ecf, nº do cupom e nº da loja), todas chaves NATURAIS. Os próprios equipamentos fiscais geram estes dados. Em 4 de março de 2010 18:26, Tarcísio Sassara sassara.tarci...@gmail.comescreveu: Em 4 de março de 2010 16:53, Alexsander Rosa alexsander.r...@gmail.com escreveu: Sim, tudo é replicado para todos os servidores (exceto as sequences). Provavelmente existem pessoas 9502/2, 9502/16, 9502/101... Não detona relatórios essas duplicidades? Relatórios do tipo Ranking podem mostrar resultados bem diferentes do real. -- Tarcisio F. Sassara ___ 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
Re: [pgbr-geral] Usando CPF/CNPJ como PK
Em 4 de março de 2010 20:13, Mozart Hasse mozart.ha...@usa.net escreveu: Ah, questão de prática. Tenho 900 tabelas para brincar e de proporção deve dar uns 60% com PK artifical contra 40% sem. Realmente base com 150GB eu não tenho, mas no meu caso a dor de cabeça é cuidar dos malditos 40% sem PK artificial em bases muito menores. Poisé, por isso que não podemos dizer que existe uma regra específica, mas um conjunto de técnicas que uma vez aplicadas a um ambiente específico conseguimos atingir um grau de manutenção satisfatório para o caso em questão. Mozart, apenas por curiosidade, essas chaves artificiais são sequences? Se sim, já aconteceu de você precisar copiar dados de outras bases para esta por exemplo? Se sim, pode nos expor como você o fez? []s Dickson S. Guedes mail/xmpp: gue...@guedesoft.net - skype: guediz http://guedesoft.net - http://www.postgresql.org.br ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
