Re: [pgbr-geral] CHAVE COMPOSTA
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 pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] CHAVE COMPOSTA
Leandro DUTRA wrote: 2008/3/26, Fernando Brombatti [EMAIL PROTECTED]: Eu, particularmente, acho que chave primária não pode, jamais, ser composta. Chave primária é primária e basta! Mas Fernando, o que tem a ver chave primária ser simples ou composta? Qual o problema? Se você tem uma chave composta perfeitamente boa, para que aumentar a complexidade do modelo, criar um índice adicional, gastar mais armazenamento, cache e eventos de E/S? Você vai ter de declarar a chave composta mesmo também… 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. Por outro lado pode até diminuir, eu tendo uma chave primária aumentando a cache e eventos E/S na tabela, vou diminuir o mesmo em tabelas relacionadas, pois não precisarei ter todos os da chave composta na relação. Se uma tabela tem mais de 1 relacionamento, acho que vamos ganhar em E/S ao invés de perder. Perde-se na tabela principal, mas ganha nas relações. Trade-off, ai seria o caso de balancear onde é melhor perder. Evandro ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] CHAVE COMPOSTA
E no lance de relacionamento n:m [tabela1]n:m[tabela2] [tabela de relacionamento] a tabela de relacionamento no caso não seria melhor se fosse criada uma chave primaria composta? Em 27/03/08, Evandro Ricardo Silvestre [EMAIL PROTECTED] escreveu: Leandro DUTRA wrote: 2008/3/26, Fernando Brombatti [EMAIL PROTECTED]: Eu, particularmente, acho que chave primária não pode, jamais, ser composta. Chave primária é primária e basta! Mas Fernando, o que tem a ver chave primária ser simples ou composta? Qual o problema? Se você tem uma chave composta perfeitamente boa, para que aumentar a complexidade do modelo, criar um índice adicional, gastar mais armazenamento, cache e eventos de E/S? Você vai ter de declarar a chave composta mesmo também… 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. Por outro lado pode até diminuir, eu tendo uma chave primária aumentando a cache e eventos E/S na tabela, vou diminuir o mesmo em tabelas relacionadas, pois não precisarei ter todos os da chave composta na relação. Se uma tabela tem mais de 1 relacionamento, acho que vamos ganhar em E/S ao invés de perder. Perde-se na tabela principal, mas ganha nas relações. Trade-off, ai seria o caso de balancear onde é melhor perder. Evandro ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral -- = Grupo Comunidade de Comunicação Rafael Lúcio 29809.099333, fazendo do seu website uma aplicação em tempo real ms xsl js(dom) css xhtml php mysql pgsql ajax json smarty drupal ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] CHAVE COMPOSTA
conceitualmente esta errado, chave primaria nao quer dizer que não seja composta e sim que a partir de um conjunto ou não de atributos você possa identificar um registro. Mas, as vezes é diíficil não conviver com o que você disse, seja por motivos de performance. É a mesma questão de manter algumas vezes os dados desnormalizados. - Original Message - From: Fernando Brombatti To: Comunidade PostgreSQL Brasileira Sent: Wednesday, March 26, 2008 8:34 PM Subject: Re: [pgbr-geral] CHAVE COMPOSTA Eu, particularmente, acho que chave primária não pode, jamais, ser composta. Chave primária é primária e basta!!! Agora, se preciso que haja uma chave composta (e isso acontece com freqüência) utilizo os UNIQUE. Testando em uma aplicação não tão grande (tabela com aproximadamente 300.000 registros) com chave primária composta e não composta notei uma diferença de performance quando usava as chaves estrangeiras, além do que o índice para os relacionamentos é maior e etc e etc e etc. Assim, a validade da chave composta (entenda-se aqui o UNIQUE) se reduz às inclusões e alterações, ou seja, o índice maior é acessados menos vezes. Pode não ter tanta lógica, mas teve diferença. Agora, cada um modela da forma que preferir. 2008/3/25 Leandro DUTRA [EMAIL PROTECTED]: 2008/3/25, junior Prado [EMAIL PROTECTED]: Estou na duvida em usar chave composta ou não. Gostaria de saber qual o impacto em usar chave composta em desempenho, indice, etc. Se possível, pros e contras... Infelizmente não é tão simples. Você *não pode deixar de usar chaves compostas*. Todas as chaves candidatas devem ser declaradas, seja como chaves primárias ou alternativas (UNIQUE). A questão é se a chave primária pode ser composta ou não. Eu sou partidário de que sim, a menos que haja muitas tabelas filhas críticas para desempenho com quantidades enormes de tuplas. Procure pelo artigo Primary Keyvil. Não concordo com todas as exceções que ele coloca, mas é um começo. Hora de blogar a respeito. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (11) 3040 7300 r155 gTalk: xmpp:[EMAIL PROTECTED] +55 (11) 9406 7191ICQ/AIM: aim:GoIM?screenname=61287803 +55 (11) 5685 2219MSN: msnim:[EMAIL PROTECTED] ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral -- Fernando Brombatti email-msn-gtalk-skype: [EMAIL PROTECTED] work: +55 54 3218-6060 mobile: +55 54 8112-7250 Visite www.datamais.com -- ___ 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] CHAVE COMPOSTA
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. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (11) 3040 7300 r155 gTalk: xmpp:[EMAIL PROTECTED] +55 (11) 9406 7191ICQ/AIM: aim:GoIM?screenname=61287803 +55 (11) 5685 2219MSN: msnim:[EMAIL PROTECTED] ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] CHAVE COMPOSTA
2008/3/26, Fernando Brombatti [EMAIL PROTECTED]: Eu, particularmente, acho que chave primária não pode, jamais, ser composta. Chave primária é primária e basta! Mas Fernando, o que tem a ver chave primária ser simples ou composta? Qual o problema? Se você tem uma chave composta perfeitamente boa, para que aumentar a complexidade do modelo, criar um índice adicional, gastar mais armazenamento, cache e eventos de E/S? Você vai ter de declarar a chave composta mesmo também… Testando em uma aplicação não tão grande (tabela com aproximadamente 300.000 registros) com chave primária composta e não composta notei uma diferença de performance quando usava as chaves estrangeiras, além do que o índice para os relacionamentos é maior e etc e etc e etc. Assim, a validade da chave composta (entenda-se aqui o UNIQUE) se reduz às inclusões e alterações, ou seja, o índice maior é acessados menos vezes. Mas veja, você fez um teste. Há muitas situações que diferem, por exemplo tabelas que não têm filhas. A sua regra as oneraria. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (11) 3040 7300 r155 gTalk: xmpp:[EMAIL PROTECTED] +55 (11) 9406 7191ICQ/AIM: aim:GoIM?screenname=61287803 +55 (11) 5685 2219MSN: msnim:[EMAIL PROTECTED] ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] CHAVE COMPOSTA
Galera, Estou na duvida em usar chave composta ou não. Gostaria de saber qual o impacto em usar chave composta em desempenho, indice, etc. Se possível, pros e contras... -- Valter Cezar Prado Junior Analista TI Sem saber como fazer ele fez! ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] CHAVE COMPOSTA
2008/3/25, junior Prado [EMAIL PROTECTED]: Estou na duvida em usar chave composta ou não. Gostaria de saber qual o impacto em usar chave composta em desempenho, indice, etc. Se possível, pros e contras... Infelizmente não é tão simples. Você *não pode deixar de usar chaves compostas*. Todas as chaves candidatas devem ser declaradas, seja como chaves primárias ou alternativas (UNIQUE). A questão é se a chave primária pode ser composta ou não. Eu sou partidário de que sim, a menos que haja muitas tabelas filhas críticas para desempenho com quantidades enormes de tuplas. Procure pelo artigo Primary Keyvil. Não concordo com todas as exceções que ele coloca, mas é um começo. Hora de blogar a respeito. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (11) 3040 7300 r155 gTalk: xmpp:[EMAIL PROTECTED] +55 (11) 9406 7191ICQ/AIM: aim:GoIM?screenname=61287803 +55 (11) 5685 2219MSN: msnim:[EMAIL PROTECTED] ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
