Re: [pgbr-geral] Bloquear Row
Em Qui, 2007-06-28 às 15:56 +0200, ..:: Rodrigo Machado ::.. escreveu: Prevendo justamente este caso que eu armazeno tambem o PID da conexao que travou o registro. Não, você está fazendo tudo errado, por falta de paciência de aprender. Por favor estude transações. Coloque teu servidor em nível de isolamento serializável. Você não vai precisar de FOR UPDATE, tua aplicação será mais simples, rápida e confiável. -- Leandro Guimarães Faria Corcete DUTRA [EMAIL PROTECTED] Atech Fundação Aplicação de Tecnologias Críticas SP, BR msnim:[EMAIL PROTECTED] skype:leandro.gfc.dutra?chat +55 (11) 3040 7300 r151 - - - - - Politica de Privacidade: Esta mensagem pode conter informacao confidencial e/ou privilegiada. Se voce nao for o destinatario ou a pessoa autorizada a receber esta mensagem, nao pode usar, copiar ou divulgar as informacoes nela contidas ou tomar qualquer acao baseada nessas informacoes. Se voce recebeu esta mensagem por engano, por favor avise imediatamente o remetente, respondendo o e-mail e em seguida apague-o. Agradecemos sua cooperacao. Privacy Policy: This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation.___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Bloquear Row
Em Qui, 2007-06-28 às 16:43 +0200, ..:: Rodrigo Machado ::.. escreveu: Mas a resposta do companheiro moises vai fazer com que eu elimine esta tabela auxiliar. SELECT * FROM clientes WHERE cod = '0001' FOR UPDATE NOWAIT.. ja testei.. e deu certo.. se um registro está bloquado, ele retorna um erro.. está otimo pra mim. Sim, é uma solução bem melhor que a totalmente manual. Mas ainda é mais manual — e portanto mais complicada e lenta, e menos escalável — que a solução transacional. -- Leandro Guimarães Faria Corcete DUTRA [EMAIL PROTECTED] Atech Fundação Aplicação de Tecnologias Críticas SP, BR msnim:[EMAIL PROTECTED] skype:leandro.gfc.dutra?chat +55 (11) 3040 7300 r151 - - - - - Politica de Privacidade: Esta mensagem pode conter informacao confidencial e/ou privilegiada. Se voce nao for o destinatario ou a pessoa autorizada a receber esta mensagem, nao pode usar, copiar ou divulgar as informacoes nela contidas ou tomar qualquer acao baseada nessas informacoes. Se voce recebeu esta mensagem por engano, por favor avise imediatamente o remetente, respondendo o e-mail e em seguida apague-o. Agradecemos sua cooperacao. Privacy Policy: This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation.___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Bloquear Row
Em Qui, 2007-06-28 às 22:44 +0200, ..:: Rodrigo Machado ::.. escreveu: Pois imagina que o FULANINHO comecou alterar um cliente, eu vou ter que manter o registro bloqueado até que o fulaninho termine Por essas e outras é que não se deve fazer na mão o que o controle de transações faz por ti. -- Leandro Guimarães Faria Corcete DUTRA [EMAIL PROTECTED] Atech Fundação Aplicação de Tecnologias Críticas SP, BR msnim:[EMAIL PROTECTED] skype:leandro.gfc.dutra?chat +55 (11) 3040 7300 r151 - - - - - Politica de Privacidade: Esta mensagem pode conter informacao confidencial e/ou privilegiada. Se voce nao for o destinatario ou a pessoa autorizada a receber esta mensagem, nao pode usar, copiar ou divulgar as informacoes nela contidas ou tomar qualquer acao baseada nessas informacoes. Se voce recebeu esta mensagem por engano, por favor avise imediatamente o remetente, respondendo o e-mail e em seguida apague-o. Agradecemos sua cooperacao. Privacy Policy: This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation.___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Bloquear Row
Em Qui, 2007-06-28 às 23:02 +0200, ..:: Rodrigo Machado ::.. escreveu: a travez da transacao.. tem como o segundo usuario saber se pode ou nao alterar o registro? e ser avisado de tal coisa? Se isto for possivel.. vou implementar na minha aplicacao O tempo que você já gastou, e ainda vai gastar, está sendo desperdiçado. Controle de transações não é tão difícil assim. -- Leandro Guimarães Faria Corcete DUTRA [EMAIL PROTECTED] Atech Fundação Aplicação de Tecnologias Críticas SP, BR msnim:[EMAIL PROTECTED] skype:leandro.gfc.dutra?chat +55 (11) 3040 7300 r151 - - - - - Politica de Privacidade: Esta mensagem pode conter informacao confidencial e/ou privilegiada. Se voce nao for o destinatario ou a pessoa autorizada a receber esta mensagem, nao pode usar, copiar ou divulgar as informacoes nela contidas ou tomar qualquer acao baseada nessas informacoes. Se voce recebeu esta mensagem por engano, por favor avise imediatamente o remetente, respondendo o e-mail e em seguida apague-o. Agradecemos sua cooperacao. Privacy Policy: This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation.___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Bloquear Row
Em Qui, 2007-06-28 às 23:33 +0200, ..:: Rodrigo Machado ::.. escreveu: Vou poder bloquear um registro, e deixalo somente leitura para todas as demais estacoes? Isso é básico no PostgreSQL. Caso em uma segunda estacao alguem tentar alterar o mesmo registro, vou poder avisalo que este registro está sendo alterado por outro usuario, ou melhor, inclusive mostrar qual usuario está bloqueando? Isso seria absurdo! Já pensou nas implicações de segurança? Desculpe o desabafo, mas por que tantos programadores querem reinventar a roda? O que aconteceu com as escolas? -- Leandro Guimarães Faria Corcete DUTRA [EMAIL PROTECTED] Atech Fundação Aplicação de Tecnologias Críticas SP, BR msnim:[EMAIL PROTECTED] skype:leandro.gfc.dutra?chat +55 (11) 3040 7300 r151 - - - - - Politica de Privacidade: Esta mensagem pode conter informacao confidencial e/ou privilegiada. Se voce nao for o destinatario ou a pessoa autorizada a receber esta mensagem, nao pode usar, copiar ou divulgar as informacoes nela contidas ou tomar qualquer acao baseada nessas informacoes. Se voce recebeu esta mensagem por engano, por favor avise imediatamente o remetente, respondendo o e-mail e em seguida apague-o. Agradecemos sua cooperacao. Privacy Policy: This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation.___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Bloquear Row
Em Qui, 2007-06-28 às 23:50 +0200, ..:: Rodrigo Machado ::.. escreveu: Acontece que como esta venda esta em aberto, quando eu for alterar.. nao vou poder permitir que dois usuarios alterem a mesma venda.. Ah, então teu problema é completamente diferente. Você fez uma transação que é um pedido em aberto. Você não quer uma transação em que um outro usuário que não o criador do pedido em aberto o altere. Esse não é um problema tecnológico, mas de programação: o seu programa não pode permitir uma alteração de pedido em aberto por quem não for o criador dele. O que o SGBD deveria te ajudar é em criar uma restrição de integridade correspondente; por exemplo, um CHECK CONSTRAINT. Mas isso ainda não é suportado (http://www.postgresql.org/docs/8.2/interactive/sql-createtable.html). A menos que se bagunce um pouco o modelo para que na mesma tupla haja o identificador de usuário criador do pedido e do alterador. -- Leandro Guimarães Faria Corcete DUTRA [EMAIL PROTECTED] Atech Fundação Aplicação de Tecnologias Críticas SP, BR msnim:[EMAIL PROTECTED] skype:leandro.gfc.dutra?chat +55 (11) 3040 7300 r151 - - - - - Politica de Privacidade: Esta mensagem pode conter informacao confidencial e/ou privilegiada. Se voce nao for o destinatario ou a pessoa autorizada a receber esta mensagem, nao pode usar, copiar ou divulgar as informacoes nela contidas ou tomar qualquer acao baseada nessas informacoes. Se voce recebeu esta mensagem por engano, por favor avise imediatamente o remetente, respondendo o e-mail e em seguida apague-o. Agradecemos sua cooperacao. Privacy Policy: This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation.___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Bloquear Row
Em Sex, 2007-06-29 às 00:19 +0200, ..:: Rodrigo Machado ::.. escreveu: neste problema o SELECT FOR UPDATE NOWAIT ja me resolve.. perfeitamente. Não resolve não. E se algum componente do sistema — servidor, rede, cliente — falhar? A tupla será liberada, e baubau. -- Leandro Guimarães Faria Corcete DUTRA [EMAIL PROTECTED] Atech Fundação Aplicação de Tecnologias Críticas SP, BR msnim:[EMAIL PROTECTED] skype:leandro.gfc.dutra?chat +55 (11) 3040 7300 r151 - - - - - Politica de Privacidade: Esta mensagem pode conter informacao confidencial e/ou privilegiada. Se voce nao for o destinatario ou a pessoa autorizada a receber esta mensagem, nao pode usar, copiar ou divulgar as informacoes nela contidas ou tomar qualquer acao baseada nessas informacoes. Se voce recebeu esta mensagem por engano, por favor avise imediatamente o remetente, respondendo o e-mail e em seguida apague-o. Agradecemos sua cooperacao. Privacy Policy: This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation.___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Pergunta de iniciante
Em Qua, 2007-06-27 às 11:46 -0300, Julian Chacel escreveu: Olá, gostaria de saber se é possível o que estou pensando fazer. Quero instalar o PostGreSQL em uma máquina Linux(Ubuntu 7.04), para armazenar grandes quantidades de informações (pode passar de 5 GB), e usar o C/C++ para acessar o banco, fazer muitos cálculos, gerar tabelas de resumo e servir esses resumos para estações Windows rodando um front-end em MS Access. Sim, por que não? -- Leandro Guimarães Faria Corcete DUTRA [EMAIL PROTECTED] Atech Fundação Aplicação de Tecnologias Críticas SP, BR msnim:[EMAIL PROTECTED] skype:leandro.gfc.dutra?chat +55 (11) 3040 7300 r151 - - - - - Politica de Privacidade: Esta mensagem pode conter informacao confidencial e/ou privilegiada. Se voce nao for o destinatario ou a pessoa autorizada a receber esta mensagem, nao pode usar, copiar ou divulgar as informacoes nela contidas ou tomar qualquer acao baseada nessas informacoes. Se voce recebeu esta mensagem por engano, por favor avise imediatamente o remetente, respondendo o e-mail e em seguida apague-o. Agradecemos sua cooperacao. Privacy Policy: This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation.___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Repetição de Tuplas (Duvida SQL)
At Wed, 27 Jun 2007 09:52:59 -0300, Evandro Ricardo Silvestre wrote: Preciso fazer um SELECT que retorna N vezes uma mesma tupla. Então… antes de responder essa pergunta, vou fazer outra: precisa mesmo? Porque a boa prática é usar um número de quantidade, não a repetição. Vide Date. Gostaria de pedir desculpas pelo topico, pois não é totalmente referente a PostgreSQL e sim a SQL. Como sei que temos grandes gurus SQL aqui, achei que alguém poderia saber. Tem a lista bancosdedados no Yahoo! para isso, embora esteja meio abandonada. -- Leandro Guimarães Faria Corcete DUTRA [EMAIL PROTECTED] Atech Fundação Aplicação de Tecnologias Críticas SP, BR msnim:[EMAIL PROTECTED] skype:leandro.gfc.dutra?chat +55 (11) 3040 7300 r151 - - - - - Politica de Privacidade: Esta mensagem pode conter informacao confidencial e/ou privilegiada. Se voce nao for o destinatario ou a pessoa autorizada a receber esta mensagem, nao pode usar, copiar ou divulgar as informacoes nela contidas ou tomar qualquer acao baseada nessas informacoes. Se voce recebeu esta mensagem por engano, por favor avise imediatamente o remetente, respondendo o e-mail e em seguida apague-o. Agradecemos sua cooperacao. Privacy Policy: This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation.___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Oitmização Postgres para acesso via internet
Em Sáb, 2007-06-23 às 10:31 -0300, jean escreveu: Eu uso uma aplicação baseado no postgres 8.1 que estava acessando em rede local, agora abri a aplicação para acesso via internet, configurei tudo bonitinho e esta funcional, mas lento na leitura como seria de se esperar. Cliente-servidor está morto, vivam os terminais! Então pergunto, o que posso mexer no postgres.conf para otimizar o acesso via web? Meu servidor é Win2000 não posso colocar linux nele, e minha conexão é de 1mbit. Use-o como servidor de terminais. Ou coloque do lado um Debian da vida, e use o NX. MS W2K ainda é suportado? -- Leandro Guimarães Faria Corcete DUTRA [EMAIL PROTECTED] Atech Fundação Aplicação de Tecnologias Críticas SP, BR msnim:[EMAIL PROTECTED] skype:leandro.gfc.dutra?chat +55 (11) 3040 7300 r151 - - - - - Politica de Privacidade: Esta mensagem pode conter informacao confidencial e/ou privilegiada. Se voce nao for o destinatario ou a pessoa autorizada a receber esta mensagem, nao pode usar, copiar ou divulgar as informacoes nela contidas ou tomar qualquer acao baseada nessas informacoes. Se voce recebeu esta mensagem por engano, por favor avise imediatamente o remetente, respondendo o e-mail e em seguida apague-o. Agradecemos sua cooperacao. Privacy Policy: This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation.___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Problemas ao acessar campo no RECORD
Em Seg, 2007-06-25 às 11:19 -0300, tacio vilela escreveu: Tenho o seguinte código: Em que linguagem? Desculpe, mas há tempos não programo e não consigo adivinhar. sql := ''; sql := 'SELECT prestadora, nomedalocalidade, nomedomunicipio '; sql := sql || 'FROM ' || schemapadrao || 'fixo '; sql := sql || 'WHERE( '; sql := sql || 'prefixo = \'' || dddchamada || substr( destino, 1, 4 ) || '\' '; sql := sql || 'AND \'' || substr(destino, 5, 4) ||'\'::integer '; sql := sql || 'BETWEEN nfaixainicial::integer AND nfaixafinal::integer'; sql := sql || ' )'; Esse tipo de coisa não devia ser feito com variáveis em vez de concatenação? Quando peço para escrever as variáveis (prestadora, localidade e municipio), é escrito apenas a variável prestadora. e pára a execução. Termina normalmente, dá mensagem de erro? -- Leandro Guimarães Faria Corcete DUTRA [EMAIL PROTECTED] Atech Fundação Aplicação de Tecnologias Críticas SP, BR msnim:[EMAIL PROTECTED] skype:leandro.gfc.dutra?chat +55 (11) 3040 7300 r151 - - - - - Politica de Privacidade: Esta mensagem pode conter informacao confidencial e/ou privilegiada. Se voce nao for o destinatario ou a pessoa autorizada a receber esta mensagem, nao pode usar, copiar ou divulgar as informacoes nela contidas ou tomar qualquer acao baseada nessas informacoes. Se voce recebeu esta mensagem por engano, por favor avise imediatamente o remetente, respondendo o e-mail e em seguida apague-o. Agradecemos sua cooperacao. Privacy Policy: This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation.___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Problemas ao acessar campo no RECORD
Em Seg, 2007-06-25 às 12:38 -0300, tacio vilela escreveu: Mas tipo eu preciso de buscar os dados baseados em duas variáveis. Nenhum problema. O que vc está dizendo é para que faça desse modo: […] sql := sql || 'FROM ' || schemapadrao || 'fixo '; De jeito nenhum. Busque por ‘bind variables’ ou ‘host variables’. Por favor, RFC 1855. -- Leandro Guimarães Faria Corcete DUTRA [EMAIL PROTECTED] Atech Fundação Aplicação de Tecnologias Críticas SP, BR msnim:[EMAIL PROTECTED] skype:leandro.gfc.dutra?chat +55 (11) 3040 7300 r151 - - - - - Politica de Privacidade: Esta mensagem pode conter informacao confidencial e/ou privilegiada. Se voce nao for o destinatario ou a pessoa autorizada a receber esta mensagem, nao pode usar, copiar ou divulgar as informacoes nela contidas ou tomar qualquer acao baseada nessas informacoes. Se voce recebeu esta mensagem por engano, por favor avise imediatamente o remetente, respondendo o e-mail e em seguida apague-o. Agradecemos sua cooperacao. Privacy Policy: This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation.___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Ferramentas de ‘Modelagem’
Em Sex, 2007-06-22 às 00:16 -0300, Gilberto C. Andrade escreveu: Uso este http://fabforce.net/dbdesigner4/. O cara que o fez parou o projeto em função do trabalho no projeto MySQL Workbench. Mas isso não impede ninguém de baixar os fontes e aplicar alguns patchs disponíveis. No momento não tive essa necessidade, o ultimo release não me deu problemas. Então, você roda em que plataforma? Eu não consegui usar da última vez que tentei. Ah, esqueci de mencionar algumas outras necessidades que talvez me atrapalhem, como lidar com esquemas e versões. -- Leandro Guimarães Faria Corcete DUTRA [EMAIL PROTECTED] Atech Fundação Aplicação de Tecnologias Críticas SP, BR msnim:[EMAIL PROTECTED] skype:leandro.gfc.dutra?chat +55 (11) 3040 7300 r151 - - - - - Politica de Privacidade: Esta mensagem pode conter informacao confidencial e/ou privilegiada. Se voce nao for o destinatario ou a pessoa autorizada a receber esta mensagem, nao pode usar, copiar ou divulgar as informacoes nela contidas ou tomar qualquer acao baseada nessas informacoes. Se voce recebeu esta mensagem por engano, por favor avise imediatamente o remetente, respondendo o e-mail e em seguida apague-o. Agradecemos sua cooperacao. Privacy Policy: This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation.___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Banco de dados Orientado a objeto
Em Qui, 2007-06-21 às 21:08 -0300, Euler Taveira de Oliveira escreveu: Leonardo Cezar wrote: E por falar em OQL, que fim se deu essa coisa??? A última versão é datada em 2001 (ODMG 3.0), mas como nem todo defunto está morto, veja [1]. Não contentes com a morte recente eles querem resuscitar o padrão com uma versão 4.0. Vamos esperar pra ver. Tem defuntos que é melhor deixar enterrado. Cheira CODASYL, seria um atraso de quase 40 anos no campo. -- Leandro Guimarães Faria Corcete DUTRA [EMAIL PROTECTED] Atech Fundação Aplicação de Tecnologias Críticas SP, BR msnim:[EMAIL PROTECTED] skype:leandro.gfc.dutra?chat +55 (11) 3040 7300 r151 - - - - - Politica de Privacidade: Esta mensagem pode conter informacao confidencial e/ou privilegiada. Se voce nao for o destinatario ou a pessoa autorizada a receber esta mensagem, nao pode usar, copiar ou divulgar as informacoes nela contidas ou tomar qualquer acao baseada nessas informacoes. Se voce recebeu esta mensagem por engano, por favor avise imediatamente o remetente, respondendo o e-mail e em seguida apague-o. Agradecemos sua cooperacao. Privacy Policy: This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation.___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Ferramentas de [UTF-8?]âModelagemâ
Em Sex, 2007-06-22 às 10:37 -0200, frozza escreveu: Aí pega mais embaixo: não descobri como tratar domínios em UML. Você pode passar um exemplo de tratamento de domínios, para melhor entender o problema? Uma base de dados não deve ser definida em cima dos tipos simples predefinidos pelo SGBD, mas por tipos definidos pelo usuário. O seguinte comando estaria errado: CREATE TABLE funcionario (cd_pessoa NUMERIC (10), salario NUMERIC (17,2)) O certo seria: CREATE DOMAIN cd_pessoa AS NUMERIC (10); CREATE DOMAIN salario AS NUMERIC (17,2); CREATE TABLE funcionario (cd_pessoa cd_pessoa, salario salario); Então é fundamental que a ferramenta de modelagem permita criar os domínios antes das relações, e depois emitir relatórios sobre os domínios c. Na verdade, minha convicção é que quem tem o privilégio de trabalhar só com PostgreSQL (por exemplo) não precisa dessas ferramentas, porque o próprio PostgreSQL lida com domínios e é trivial usar depois o AutoDoc e outras ferramentas para os relatórios e diagramas. Meu problema é precisar de uma ferramenta que cubra vários SGBDs, inclusive aqueles que não suportam domínios como Oracle, MS SQL Server e MySQL. -- Leandro Guimarães Faria Corcete DUTRA [EMAIL PROTECTED] Atech Fundação Aplicação de Tecnologias Críticas SP, BR msnim:[EMAIL PROTECTED] skype:leandro.gfc.dutra?chat +55 (11) 3040 7300 r151 - - - - - Politica de Privacidade: Esta mensagem pode conter informacao confidencial e/ou privilegiada. Se voce nao for o destinatario ou a pessoa autorizada a receber esta mensagem, nao pode usar, copiar ou divulgar as informacoes nela contidas ou tomar qualquer acao baseada nessas informacoes. Se voce recebeu esta mensagem por engano, por favor avise imediatamente o remetente, respondendo o e-mail e em seguida apague-o. Agradecemos sua cooperacao. Privacy Policy: This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation.___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Ferramentas de ‘Modelagem’
Em Sex, 2007-06-22 às 10:06 -0400, Gilberto C. Andrade escreveu: SuSe 9.0, depois SuSe 9.3 e agora OpenSuse 10.2 Interessante. Sem remendos? E onde ficam esses remendos que você mencionou? E por favor, RFC 1855! -- Leandro Guimarães Faria Corcete DUTRA [EMAIL PROTECTED] Atech Fundação Aplicação de Tecnologias Críticas SP, BR msnim:[EMAIL PROTECTED] skype:leandro.gfc.dutra?chat +55 (11) 3040 7300 r151 - - - - - Politica de Privacidade: Esta mensagem pode conter informacao confidencial e/ou privilegiada. Se voce nao for o destinatario ou a pessoa autorizada a receber esta mensagem, nao pode usar, copiar ou divulgar as informacoes nela contidas ou tomar qualquer acao baseada nessas informacoes. Se voce recebeu esta mensagem por engano, por favor avise imediatamente o remetente, respondendo o e-mail e em seguida apague-o. Agradecemos sua cooperacao. Privacy Policy: This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Ferramentas de ‘Modelagem’
Em Sex, 2007-06-22 às 11:26 -0300, Wallace Reis escreveu: Mas interessante, de fato o domínio é uma restrição, a mais fundamental que existe. Tem algum link para algum tutorial ensinando a fazer isso nalguma ferramenta UML livre ou pelo menos popular? Tutorial não. Mas sei que uma boa ferramenta, o JUDE[1]. Tomara que eu não gaste tempo demais aprendendo isso, o projeto já está apertado. A UML diz que tem várias visões do modelo, você pode modelar um diagrama que seja a visão das constraints do modelo. Resta ainda a ver o resto das restrições: CHECK, transição c. Mas essas o DER também não faz, vai via texto mesmo. Tomara que dê para fazer em UML. -- Leandro Guimarães Faria Corcete DUTRA [EMAIL PROTECTED] Atech Fundação Aplicação de Tecnologias Críticas SP, BR msnim:[EMAIL PROTECTED] skype:leandro.gfc.dutra?chat +55 (11) 3040 7300 r151 - - - - - Politica de Privacidade: Esta mensagem pode conter informacao confidencial e/ou privilegiada. Se voce nao for o destinatario ou a pessoa autorizada a receber esta mensagem, nao pode usar, copiar ou divulgar as informacoes nela contidas ou tomar qualquer acao baseada nessas informacoes. Se voce recebeu esta mensagem por engano, por favor avise imediatamente o remetente, respondendo o e-mail e em seguida apague-o. Agradecemos sua cooperacao. Privacy Policy: This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation.___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] otimizacao de queries
De alguma maneira não li esta mensagem de ontem. Em Qui, 2007-06-21 às 15:37 -0300, Wallace Reis escreveu: On 6/21/07, Leandro Guimaraes Faria Corcete DUTRA [EMAIL PROTECTED] wrote: Por que vai? Degradação de performance. No meu caso com cerca de 19 milhões de registros em uma única tabela ajuda, e muito. Só se as grandes tabelas forem filhas de tabelas com chaves primárias compostas. Caso contrário, você ganha por não ter de acrescentar mais um atributo. Ao meu ver, o ideal é usar uma chave natural *não inteligente* como chave primária, quando não puder ae cabe o uso de chave artificial. O ideal é usar qualquer chave natural. Esse conceito de ’chave inteligente’ é bastante subjetivo. Você vai ter que alterar o check constraint para a nova lógica e executar uma operação de update e com o on cascade, a depender do seu bd, em várias tabelas que contém milhões de registros. Se você pensar em um banco de currículos ou um forúm que são ambientes com pequeno volume de dados, neste caso você tem razão. Rapaz, não vejo como o CPF ou o RG vão mudar tão drasticamente. Como falei, esse conceito de chave inteligente não é muito útil… principalmente se uma chave externa é considerada inteligente! A ironia que o Gilberto fez foi exatemente a msm que uma pessoa fez na usenet e a resposta do JOE CELKO foi: Dr. Codd would be VERY surprised to find out that his papers had no mention of primary keys in them.; claro que a cláusula SQL PRIMARY KEY tem adições de propriedades ao conceito de chave primária criado por Dr. Codd. Na verdade tem de haver chave(s) natural(is). A questão de qual será a primária é completamente arbitrária. No SQL é obrigatório, no modelo relacional não. p.s.: acredito que o assunto ta fugindo do inicial da thread. acho até melhor continuarmos a conversar em privado diretamente no email pessoal do que pela lista, pois vc tem colocado muita emoção e se exaltado em suas mensagens. É uma lista de discussões, certo? Eu me exalto pela verdade. Não suporto o tanto de confusão que se tem gerado na área, atrapalhando imenso o progresso. -- Leandro Guimarães Faria Corcete DUTRA [EMAIL PROTECTED] Atech Fundação Aplicação de Tecnologias Críticas SP, BR msnim:[EMAIL PROTECTED] skype:leandro.gfc.dutra?chat +55 (11) 3040 7300 r151 - - - - - Politica de Privacidade: Esta mensagem pode conter informacao confidencial e/ou privilegiada. Se voce nao for o destinatario ou a pessoa autorizada a receber esta mensagem, nao pode usar, copiar ou divulgar as informacoes nela contidas ou tomar qualquer acao baseada nessas informacoes. Se voce recebeu esta mensagem por engano, por favor avise imediatamente o remetente, respondendo o e-mail e em seguida apague-o. Agradecemos sua cooperacao. Privacy Policy: This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation.___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] SELECT JOIN
Em Sex, 2007-06-22 às 12:03 -0300, Thiago Risso escreveu: Consegui melhorar Bastante o plano de execução invertendo a tabela no qual é realizada o seqScan Inicial : EXPLAIN SELECT L.id_log,RL.id_log FROM tzrepl.tzr_replicated_log RL RIGHT OUTER JOIN tzrepl.tzr_log L ON L.id_log = RL.id_log WHERE RL.id_log IS NULL Legal, mas sem identação está chato de ler e comparar. Aliás, já apaguei as mensagens anteriores… preciso parar de fazê-lo. Mas mesmo assim vou tentar implementar o num_repl, que reduzirá ainda mais a quantidade de linhas do primeiro seqScan... O que acham ? Me pareceu, superficialmente, redundância, que é feio e pode prejudicar. Mas não analisei a fundo, nem o farei… -- Leandro Guimarães Faria Corcete DUTRA [EMAIL PROTECTED] Atech Fundação Aplicação de Tecnologias Críticas SP, BR msnim:[EMAIL PROTECTED] skype:leandro.gfc.dutra?chat +55 (11) 3040 7300 r151 - - - - - Politica de Privacidade: Esta mensagem pode conter informacao confidencial e/ou privilegiada. Se voce nao for o destinatario ou a pessoa autorizada a receber esta mensagem, nao pode usar, copiar ou divulgar as informacoes nela contidas ou tomar qualquer acao baseada nessas informacoes. Se voce recebeu esta mensagem por engano, por favor avise imediatamente o remetente, respondendo o e-mail e em seguida apague-o. Agradecemos sua cooperacao. Privacy Policy: This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation.___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Ferramentas de ‘Modelagem’
Em Sex, 2007-06-22 às 10:48 -0400, Gilberto C. Andrade escreveu: E por favor, RFC 1855! Por que? Violei alguma regra? Sim, a própria RFC 1855. Leitura obrigatória para quem participa de listas de discussões e grupos de notícias. -- Leandro Guimarães Faria Corcete DUTRA [EMAIL PROTECTED] Atech Fundação Aplicação de Tecnologias Críticas SP, BR msnim:[EMAIL PROTECTED] skype:leandro.gfc.dutra?chat +55 (11) 3040 7300 r151 - - - - - Politica de Privacidade: Esta mensagem pode conter informacao confidencial e/ou privilegiada. Se voce nao for o destinatario ou a pessoa autorizada a receber esta mensagem, nao pode usar, copiar ou divulgar as informacoes nela contidas ou tomar qualquer acao baseada nessas informacoes. Se voce recebeu esta mensagem por engano, por favor avise imediatamente o remetente, respondendo o e-mail e em seguida apague-o. Agradecemos sua cooperacao. Privacy Policy: This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Ferramentas de ‘Modelagem’
Em Sex, 2007-06-22 às 11:14 -0400, Gilberto C. Andrade escreveu: Em 22/06/07, Leandro Guimaraes Faria Corcete DUTRA [EMAIL PROTECTED] escreveu: Em Sex, 2007-06-22 às 10:48 -0400, Gilberto C. Andrade escreveu: Por que? Violei alguma regra? Sim, a própria RFC 1855. Leitura obrigatória para quem participa de listas de discussões e grupos de notícias. Já li! Já participo de outras listas de discussão a algum tempo e aqui me parece que as coisa não são diferentes das outras. Então, por favor me diga o que estou violando! O meu cliente é o proprio gmail.com, ou seja o browser. O navegador é irrelevante. Não sei como funciona no GMail, mas a idéia é que o texto a que se responde tem de ser precedido de um sinal de ‘maior que’, como você vê acima. Em vez disso, teu cliente está identando. Fica confuso entender quem escreveu o quê e respondeu a quem. -- Leandro Guimarães Faria Corcete DUTRA [EMAIL PROTECTED] Atech Fundação Aplicação de Tecnologias Críticas SP, BR msnim:[EMAIL PROTECTED] skype:leandro.gfc.dutra?chat +55 (11) 3040 7300 r151 - - - - - Politica de Privacidade: Esta mensagem pode conter informacao confidencial e/ou privilegiada. Se voce nao for o destinatario ou a pessoa autorizada a receber esta mensagem, nao pode usar, copiar ou divulgar as informacoes nela contidas ou tomar qualquer acao baseada nessas informacoes. Se voce recebeu esta mensagem por engano, por favor avise imediatamente o remetente, respondendo o e-mail e em seguida apague-o. Agradecemos sua cooperacao. Privacy Policy: This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation.___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] SELECT JOIN
Em Sex, 2007-06-22 às 12:19 -0300, Thiago Risso escreveu: Consegui melhorar Bastante o plano de execução invertendo a tabela no qual é realizada o seqScan Inicial : EXPLAIN SELECT L.id_log,RL.id_log FROM tzrepl.tzr_replicated_log RL RIGHT OUTER JOIN tzrepl.tzr_log L ON L.id_log = RL.id_log WHERE RL.id_log IS NULL EXPLAIN SELECT L.id_log,RL.id_log FROM tzrepl.tzr_replicated_log RL RIGHT OUTER JOIN tzrepl.tzr_log L ON L.id_log = RL.id_log WHERE RL.id_log IS NULL Fica difícil comparar sem identação. Como já disse antes... Sou um pouco teimoso.. Só acredito vendo ...Vou testar ... Caso não me de resultado esperado... Removo Afinal... Testes servem para isso (Colocar em teste o que a teoria explica)... Mas você nem leu a teoria! -- Leandro Guimarães Faria Corcete DUTRA [EMAIL PROTECTED] Atech Fundação Aplicação de Tecnologias Críticas SP, BR msnim:[EMAIL PROTECTED] skype:leandro.gfc.dutra?chat +55 (11) 3040 7300 r151 - - - - - Politica de Privacidade: Esta mensagem pode conter informacao confidencial e/ou privilegiada. Se voce nao for o destinatario ou a pessoa autorizada a receber esta mensagem, nao pode usar, copiar ou divulgar as informacoes nela contidas ou tomar qualquer acao baseada nessas informacoes. Se voce recebeu esta mensagem por engano, por favor avise imediatamente o remetente, respondendo o e-mail e em seguida apague-o. Agradecemos sua cooperacao. Privacy Policy: This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation.___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] SELECT JOIN
Em Sex, 2007-06-22 às 13:31 -0300, Thiago Risso escreveu: Tem gente que aprende no caminho. Mas aí tem de começar com um alvo bem modesto. Não estou querendo abraçar o mundo, apenas estou desenvolvendo algo que resolva meu problema... Teve um carinha que só queria resolver seu problema, e criou o CP/M. Aí teve um outro que queria resolver o seu, e ‘cometeu’ o MS-DOS. Esse mesmo, em vez de consertá-lo, criou o MS Windows. E olha a bagunça onde estamos. Idem ibidem para o MySQL. É diferente dum Linus, que quando foi resolver seu problema tinha 20 anos de Unix para se basear. -- Leandro Guimarães Faria Corcete DUTRA [EMAIL PROTECTED] Atech Fundação Aplicação de Tecnologias Críticas SP, BR msnim:[EMAIL PROTECTED] skype:leandro.gfc.dutra?chat +55 (11) 3040 7300 r151 - - - - - Politica de Privacidade: Esta mensagem pode conter informacao confidencial e/ou privilegiada. Se voce nao for o destinatario ou a pessoa autorizada a receber esta mensagem, nao pode usar, copiar ou divulgar as informacoes nela contidas ou tomar qualquer acao baseada nessas informacoes. Se voce recebeu esta mensagem por engano, por favor avise imediatamente o remetente, respondendo o e-mail e em seguida apague-o. Agradecemos sua cooperacao. Privacy Policy: This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation.___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] SELECT JOIN
Em Sex, 2007-06-22 às 15:17 -0300, Daniel Loureiro escreveu: Thiago Risso escreveu: Quem sabe alguém não se inspire nas falhas/erros/bagunças do meu Propagador de Registros Assinc. e crie um SISTEMA DE REPLICAÇÃO MULTIMASTER ASSINCRONO COM RESOLUÇÃO DE CONFLITOS AUTOMÁTICAS (SRMA/RCA) assim como CSMA/CD... talvez ? Mas por agora ... Infelizmente ... Resolver meu problema é o que importa... Não tenho intenção de acabar com a FOME no mundo . Eu acredito que é graças a este espírito, que grandes idéias nascem. E quando se ignora toda a experiência do passado? Quanto a algumas críticas de reiventar a roda, ignore-as. Quando você faz algo do zero, por conta própria, você não adquire os vícios de outros projetos, você vê as coisas de uma forma totalmente diferente: e daí podem nascer grandes soluções. O importante é que você tenha criatividade e goste do que faz. Se você não conseguir ir adiante, pelo menos você vai adquirir um grande conhecimento no assunto. O problema é justamente esse, ignorar o conhecimento já acumulado. Mas boa sorte… apenas fico com pena ao ver tanto esforço desperdiçado, que poderia ir para melhorias reais do sistema. -- Leandro Guimarães Faria Corcete DUTRA [EMAIL PROTECTED] Atech Fundação Aplicação de Tecnologias Críticas SP, BR msnim:[EMAIL PROTECTED] skype:leandro.gfc.dutra?chat +55 (11) 3040 7300 r151 - - - - - Politica de Privacidade: Esta mensagem pode conter informacao confidencial e/ou privilegiada. Se voce nao for o destinatario ou a pessoa autorizada a receber esta mensagem, nao pode usar, copiar ou divulgar as informacoes nela contidas ou tomar qualquer acao baseada nessas informacoes. Se voce recebeu esta mensagem por engano, por favor avise imediatamente o remetente, respondendo o e-mail e em seguida apague-o. Agradecemos sua cooperacao. Privacy Policy: This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation.___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] SELECT JOIN
Em Sex, 2007-06-22 às 16:15 -0300, Daniel Loureiro escreveu: Hein ??? você tem um problema e precisa chegar numa solução: o que isto tem de arte ou técnica ? É o caso dele: ele precisa ter os mesmos dados em um lugar e em outro. Isto não tem nada a ver com programação, arte ou técnica. Paro por aqui. CQD. Feliz Idade das Trevas II para todo mundo! :-) 1.nem sempre: muitos cientistas resolvem os mesmos problemas de formas independentes. Exemplos? -- Leandro Guimarães Faria Corcete DUTRA [EMAIL PROTECTED] Atech Fundação Aplicação de Tecnologias Críticas SP, BR msnim:[EMAIL PROTECTED] skype:leandro.gfc.dutra?chat +55 (11) 3040 7300 r151 - - - - - Politica de Privacidade: Esta mensagem pode conter informacao confidencial e/ou privilegiada. Se voce nao for o destinatario ou a pessoa autorizada a receber esta mensagem, nao pode usar, copiar ou divulgar as informacoes nela contidas ou tomar qualquer acao baseada nessas informacoes. Se voce recebeu esta mensagem por engano, por favor avise imediatamente o remetente, respondendo o e-mail e em seguida apague-o. Agradecemos sua cooperacao. Privacy Policy: This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation.___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] SELECT JOIN
Em Sex, 2007-06-22 às 17:23 -0300, Daniel Loureiro escreveu: Leandro Guimaraes Faria Corcete DUTRA escreveu: Paro por aqui. CQD. Feliz Idade das Trevas II para todo mundo! :-) você é um pouco negativo não ? Só porque eu penso diferente de você, não significa que estou errado. http://www.apa.org/journals/features/psp7761121.pdf 1.nem sempre: muitos cientistas resolvem os mesmos problemas de formas independentes. Exemplos? arco e flexa, canoa, hierarquia de civilizações, escrita, etc. Não entendi onde tem ciência aí. É por isto, que sou contra a propriedade intelectual de idéias: ninguém possui uma idéia, apenas foi o primeiro a vê-la. Acredito que se os ocidentais nunca tivesse chegado na América (por motivos religiosos, por exemplo), teríamos aqui: computadores, lâmpadas, carros, etc. Ah, sim. E por que nos milhares de anos anteriores não tivemos? Aliás, porque o MySQL ainda não presta? Enfim, já ficou fora de tópico. Paro por aqui. -- Leandro Guimarães Faria Corcete DUTRA [EMAIL PROTECTED] Atech Fundação Aplicação de Tecnologias Críticas SP, BR msnim:[EMAIL PROTECTED] skype:leandro.gfc.dutra?chat +55 (11) 3040 7300 r151 - - - - - Politica de Privacidade: Esta mensagem pode conter informacao confidencial e/ou privilegiada. Se voce nao for o destinatario ou a pessoa autorizada a receber esta mensagem, nao pode usar, copiar ou divulgar as informacoes nela contidas ou tomar qualquer acao baseada nessas informacoes. Se voce recebeu esta mensagem por engano, por favor avise imediatamente o remetente, respondendo o e-mail e em seguida apague-o. Agradecemos sua cooperacao. Privacy Policy: This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation.___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] otimizacao de queries
Em Qua, 2007-06-20 às 23:28 -0300, Wallace Reis escreveu: On 6/20/07, Euler Taveira de Oliveira [EMAIL PROTECTED] wrote: Quanto a utilização de uma chave inteira artificial, bem nós já sabemos que conceitualmente é desnecessário e impróprio. Vale lembrar, como já disse a um tempo atrás, que também é má prática o uso de chaves naturais *inteligentes* (esqueci dessa palavra na época) como PK's. Não lembro disso, ponteiros? -- Leandro Guimarães Faria Corcete DUTRA [EMAIL PROTECTED] Atech Fundação Aplicação de Tecnologias Críticas SP, BR msnim:[EMAIL PROTECTED] skype:leandro.gfc.dutra?chat +55 (11) 3040 7300 r151 - - - - - Politica de Privacidade: Esta mensagem pode conter informacao confidencial e/ou privilegiada. Se voce nao for o destinatario ou a pessoa autorizada a receber esta mensagem, nao pode usar, copiar ou divulgar as informacoes nela contidas ou tomar qualquer acao baseada nessas informacoes. Se voce recebeu esta mensagem por engano, por favor avise imediatamente o remetente, respondendo o e-mail e em seguida apague-o. Agradecemos sua cooperacao. Privacy Policy: This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation.___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] OFF-TOPIC Banco de dados Orientado a objeto
Em Qua, 2007-06-20 às 18:19 -0300, Eduardo escreveu: OFF-TOPIC Off-topic, off-list. Leandro Nada a ver comigo, estou tentando justamente demover quem quer estudar BDOO. Veja! não deve ser seu trabalho pois este eh de outra pessoa, mas como base pra iniciar sua pesquisa é uma ótima fonte de informações, pelo menos um belo ponto de partida Como pode ser um belo ponto de partida sem sólidas bases conceituais? -- Leandro Guimarães Faria Corcete DUTRA [EMAIL PROTECTED] Atech Fundação Aplicação de Tecnologias Críticas SP, BR msnim:[EMAIL PROTECTED] skype:leandro.gfc.dutra?chat +55 (11) 3040 7300 r151 - - - - - Politica de Privacidade: Esta mensagem pode conter informacao confidencial e/ou privilegiada. Se voce nao for o destinatario ou a pessoa autorizada a receber esta mensagem, nao pode usar, copiar ou divulgar as informacoes nela contidas ou tomar qualquer acao baseada nessas informacoes. Se voce recebeu esta mensagem por engano, por favor avise imediatamente o remetente, respondendo o e-mail e em seguida apague-o. Agradecemos sua cooperacao. Privacy Policy: This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation.___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Banco de dados Orientado a objeto
Em Qua, 2007-06-20 às 02:31 -0300, Andre Vargas escreveu: O SGBD orientado a objeto foi uma idéia que surgiu no final dos anos 80, para armazenar imagens e dados de projetos de engenharia. A idéia acabou não dando muito certo principalmente porque os CPDs (principal cliente na época) não quis trocar toda sua base e aplicações em algo tão recente. Não, nada a ver. É porque não funciona bem mesmo, e é muito mais complicado que o relacional. Bem, por isso acho que tu vai encontrar pouca coisa nova. Banco mesmo tem o Caché Ironia: o Caché nada mais é que o Pick (multi-valorado) com interfaces Java. O que mostra quão pouco de substância há nos BDOO. e os Objeto-Relacionais (como o nosso PostgreSQL), que é uma tentativa de migrar mais suavemente do relacional para os objetos. Fracassada, aliás. Uma das heranças dos SGBDOO são as interfaces de dados, ou as camadas de persistência, como o Hibernate. Que são uma das grandes dores de cabeça dos ADs e ABDs. -- Leandro Guimarães Faria Corcete DUTRA [EMAIL PROTECTED] Atech Fundação Aplicação de Tecnologias Críticas SP, BR msnim:[EMAIL PROTECTED] skype:leandro.gfc.dutra?chat +55 (11) 3040 7300 r151 - - - - - Politica de Privacidade: Esta mensagem pode conter informacao confidencial e/ou privilegiada. Se voce nao for o destinatario ou a pessoa autorizada a receber esta mensagem, nao pode usar, copiar ou divulgar as informacoes nela contidas ou tomar qualquer acao baseada nessas informacoes. Se voce recebeu esta mensagem por engano, por favor avise imediatamente o remetente, respondendo o e-mail e em seguida apague-o. Agradecemos sua cooperacao. Privacy Policy: This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation.___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Banco de dados Orientado a objeto
Em Qui, 2007-06-21 às 10:52 -0300, Carlos Júnior ..::.. Boa Noite BH escreveu: puts, cara mais negativo Justamente, um dos motivos pelos quais nossa área praticamente não avança é a aversão a críticas. Pensem bem, o PostgreSQL é fantástico, e melhora a cada dia. Mas a linguagem SQL tem problemas sérios, e nenhuma solução à vista. -- Leandro Guimarães Faria Corcete DUTRA [EMAIL PROTECTED] Atech Fundação Aplicação de Tecnologias Críticas SP, BR msnim:[EMAIL PROTECTED] skype:leandro.gfc.dutra?chat +55 (11) 3040 7300 r151 - - - - - Politica de Privacidade: Esta mensagem pode conter informacao confidencial e/ou privilegiada. Se voce nao for o destinatario ou a pessoa autorizada a receber esta mensagem, nao pode usar, copiar ou divulgar as informacoes nela contidas ou tomar qualquer acao baseada nessas informacoes. Se voce recebeu esta mensagem por engano, por favor avise imediatamente o remetente, respondendo o e-mail e em seguida apague-o. Agradecemos sua cooperacao. Privacy Policy: This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation.___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] SELECT JOIN
Em Qui, 2007-06-21 às 11:30 -0300, Thiago Risso escreveu: Qual a melhor forma de eu trazer em um select de duas tabelas (POR EXEMPLO pessoa e pessoa_telefone) somente aquelas que não possuam nenhum telefone cadastrado. Hoje em dia faço da seguinte forma ... Mas acho que isso é muito desperdício : EXPLAIN SELECT * FROM tzr_log L LEFT OUTER JOIN tzr_replicated_log RL ON RL.id_log = RL.id_log WHERE RL.id_log IS NULL; Você vem de MySQL? Parece típico de MySQL, porque ele implementa subconsultas mal. Eu faria: SELECT atributos FROM esquema.tzr_log AS l WHERE l.id_log NOT IN (SELECT r.id_log FROM esquema.tzr_replicated_logAS r) ; Ou com NOT EXISTS, não sei se algum é mais eficiente que o outro no PostgreSQL. Teoricamente são equivalentes. Pois assim ele irá efetuar seqScan nas duas tabelas ... e só depois aplicar o filtro ... Mas pense bem, é um problema difícil. Você tem de ver quem existe numa e não existe na outra; ou seja, você dificultou muito a seletividade, caso em que vale a pena percorrer toda a relação. Em outros termos, como resolver a consulta sem percorrer ao menos uma relação? O melhor dos mundos seria, por exemplo, percorrer a tzr_log e, a partir de seu índice, o índice da tzr_replicated_log, evitando a tabela tzr_replicated_log em si. Aliás, teu modelo parece estranho. Como é que pessoas estão em tzr_log e telefones em tzr_replicated_log? -- Leandro Guimarães Faria Corcete DUTRA [EMAIL PROTECTED] Atech Fundação Aplicação de Tecnologias Críticas SP, BR msnim:[EMAIL PROTECTED] skype:leandro.gfc.dutra?chat +55 (11) 3040 7300 r151 - - - - - Politica de Privacidade: Esta mensagem pode conter informacao confidencial e/ou privilegiada. Se voce nao for o destinatario ou a pessoa autorizada a receber esta mensagem, nao pode usar, copiar ou divulgar as informacoes nela contidas ou tomar qualquer acao baseada nessas informacoes. Se voce recebeu esta mensagem por engano, por favor avise imediatamente o remetente, respondendo o e-mail e em seguida apague-o. Agradecemos sua cooperacao. Privacy Policy: This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation.___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Banco de dados Orientado a objeto
Em Qui, 2007-06-21 às 11:54 -0300, Carlos Júnior ..::.. Boa Noite BH escreveu: Críticas são muito bem vindas, sempre. Mais temos pontos positivos sim. Claro, relacional é muito melhor que OO, e SQL muito melhor que XML, e o PostgreSQL muito melhor que o MySQL, e a v8 bem melhor que a v7. Ninguém está questionando esses pontos pacíficos. Heraça no postgresql é bastante precário ainda, mais já existe e tende a crescer nas próximas versões. Por exemplo. Aí é que está o problema de reagir às críticas sem entendê-las. O problema não é a implementação de herança no PostgreSQL; é a própria idéia de herança de relações. Herança serve para *tipos*, como aliás na OO (classes). O drama é mapear classes para relações. -- Leandro Guimarães Faria Corcete DUTRA [EMAIL PROTECTED] Atech Fundação Aplicação de Tecnologias Críticas SP, BR msnim:[EMAIL PROTECTED] skype:leandro.gfc.dutra?chat +55 (11) 3040 7300 r151 - - - - - Politica de Privacidade: Esta mensagem pode conter informacao confidencial e/ou privilegiada. Se voce nao for o destinatario ou a pessoa autorizada a receber esta mensagem, nao pode usar, copiar ou divulgar as informacoes nela contidas ou tomar qualquer acao baseada nessas informacoes. Se voce recebeu esta mensagem por engano, por favor avise imediatamente o remetente, respondendo o e-mail e em seguida apague-o. Agradecemos sua cooperacao. Privacy Policy: This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation.___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] otimizacao de queries
Em Qui, 2007-06-21 às 09:41 -0400, Gilberto C. Andrade escreveu: On 6/20/07, Euler Taveira de Oliveira [EMAIL PROTECTED] wrote: Quanto a utilização de uma chave inteira artificial, bem nós já sabemos que conceitualmente é desnecessário e impróprio. Isso se vc não souber usar! Você teria de se explicar, a teoria é bem clara a esse respeito: chaves artificiais engordam e obscurecem o modelo. Interessante, um fala que é impróprio usar as chamadas surrogates key Então, mal-chamadas… as chaves artificais do Codd não eram para aparecer no modelo lógico, eram apenas uma otimização física. e o outro fala que é má pratica usar campos que realmente são candidatos a chave primária. Conclusão, deixa sem chave mesmo! hehe Esse está errado, e fim de papo. Não faz sentido. -- Leandro Guimarães Faria Corcete DUTRA [EMAIL PROTECTED] Atech Fundação Aplicação de Tecnologias Críticas SP, BR msnim:[EMAIL PROTECTED] skype:leandro.gfc.dutra?chat +55 (11) 3040 7300 r151 - - - - - Politica de Privacidade: Esta mensagem pode conter informacao confidencial e/ou privilegiada. Se voce nao for o destinatario ou a pessoa autorizada a receber esta mensagem, nao pode usar, copiar ou divulgar as informacoes nela contidas ou tomar qualquer acao baseada nessas informacoes. Se voce recebeu esta mensagem por engano, por favor avise imediatamente o remetente, respondendo o e-mail e em seguida apague-o. Agradecemos sua cooperacao. Privacy Policy: This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation.___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Banco de dados Orientado a objeto
Em Qui, 2007-06-21 às 13:25 -0300, Welington R. Braga escreveu: verifique o db4o: http://www.db4o.com/ Da página principal deles: ‘…store even the most complex object structures with only one line of code. db4o slashes development cost and time, provides superior performance, and requires no DBA.’ Caramba, quanta bobagem junta. -- Leandro Guimarães Faria Corcete DUTRA [EMAIL PROTECTED] Atech Fundação Aplicação de Tecnologias Críticas SP, BR msnim:[EMAIL PROTECTED] skype:leandro.gfc.dutra?chat +55 (11) 3040 7300 r151 - - - - - Politica de Privacidade: Esta mensagem pode conter informacao confidencial e/ou privilegiada. Se voce nao for o destinatario ou a pessoa autorizada a receber esta mensagem, nao pode usar, copiar ou divulgar as informacoes nela contidas ou tomar qualquer acao baseada nessas informacoes. Se voce recebeu esta mensagem por engano, por favor avise imediatamente o remetente, respondendo o e-mail e em seguida apague-o. Agradecemos sua cooperacao. Privacy Policy: This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Banco de dados Orientado a objeto
Em Qui, 2007-06-21 às 13:52 -0300, Tiago José Adami escreveu: Uma das heranças dos SGBDOO são as interfaces de dados, ou as camadas de persistência, como o Hibernate. Que são uma das grandes dores de cabeça dos ADs e ABDs. Quais, exatamente, são estas dores de cabeça? Uma vez que existe uma camada própria para tratamento dos dados, isto não facilitaria a vida de um DBA? Basicamente essas camadas dão pouquíssimo ganho e geram muita confusão. Elas servem para evitar que o programador tenha de escrever SQL, que é trivial, e acabam escrevendo Java ou outra linguagem, que não é tanto. E o programador acaba não sabendo exatamente que SQL está sendo executado, o que gera problemas como, por exemplo, mau desempenho. Mas o mais grave é na modelagem. O desenvolvedor fica tentado a simplesmente traduzir seu diagrama de classes, sem nunca entender modelagem de dados. O modelo fica complexo, ruim, perde informação, tem péssimo desempenho. Bem típico são aplicações sem controle de transações — porque muitas camadas de persistência têm AUTOCOMMIT por default — e bases sem restrições de integridade, porque as camadas só ‘conhecem’ chaves primárias e estrangeiras, e implementam as primárias como campos de autoincremento. Claro, muito disso é cultura. Um bom desenvolvedor pode até usar bem uma camada dessas; o problema é que as camadas estão atrapalhando que os desenvolvedores aprendam o suficiente para se tornarem bons. -- Leandro Guimarães Faria Corcete DUTRA [EMAIL PROTECTED] Atech Fundação Aplicação de Tecnologias Críticas SP, BR msnim:[EMAIL PROTECTED] skype:leandro.gfc.dutra?chat +55 (11) 3040 7300 r151 - - - - - Politica de Privacidade: Esta mensagem pode conter informacao confidencial e/ou privilegiada. Se voce nao for o destinatario ou a pessoa autorizada a receber esta mensagem, nao pode usar, copiar ou divulgar as informacoes nela contidas ou tomar qualquer acao baseada nessas informacoes. Se voce recebeu esta mensagem por engano, por favor avise imediatamente o remetente, respondendo o e-mail e em seguida apague-o. Agradecemos sua cooperacao. Privacy Policy: This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation.___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] otimizacao de queries
Em Qui, 2007-06-21 às 13:55 -0300, Wallace Reis escreveu: Interessante, um fala que é impróprio usar as chamadas surrogates key e o outro fala que é má pratica usar campos que realmente são candidatos a chave primária. Realmente, eles são *candidatos* a chave primária, mas acredito ser má pratica porque: i) é uma chave que você não tem controle sobre ela, então no dia que o governo resolver mudar a lógica do CPF ou do RG isso vai te trazer grandes dores de cabeça Por que vai? Em último caso, ON UPDATE CASCADE e fim de papo. Eu não vejo problema algum. Uma mudança nas chaves naturais é uma mudança drástica intrinsecamente, não vai ser uma chave artificial que vai ajudar. ii) é uma chave que contém informações (ex. no CPF dos baianos o último dígito antes do - é 5), o que não é objetivo, descrição dos dados, de uma chave primária E daí? O CPF é informado externamente, não tem problema algum. O problema é se você mistura várias informações em atributos que você mesmo gera, independente de serem chaves ou não. Em último caso, CHECK CONSTRAINT. iii) são chaves naturais no Brasil, logo restringe seu banco de dados a brasileiros. Esse é um problema de modelagem. Você criou uma entidade ‘brasileiro’, não uma entidade ’pessoa’. Enfim por estas e outras razões (que não me recordo no momento) disse ser má prática, não que é proibido. Não, é ótima prática. Não. Toda tabela *deve* ter uma chave primária. Toda tabela *tem* de ter ao menos uma chave natural. A questão de ser primária é bem arbitrária. Chaves artificiais podem até complementar as naturais, mas nunca substituir. -- Leandro Guimarães Faria Corcete DUTRA [EMAIL PROTECTED] Atech Fundação Aplicação de Tecnologias Críticas SP, BR msnim:[EMAIL PROTECTED] skype:leandro.gfc.dutra?chat +55 (11) 3040 7300 r151 - - - - - Politica de Privacidade: Esta mensagem pode conter informacao confidencial e/ou privilegiada. Se voce nao for o destinatario ou a pessoa autorizada a receber esta mensagem, nao pode usar, copiar ou divulgar as informacoes nela contidas ou tomar qualquer acao baseada nessas informacoes. Se voce recebeu esta mensagem por engano, por favor avise imediatamente o remetente, respondendo o e-mail e em seguida apague-o. Agradecemos sua cooperacao. Privacy Policy: This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation.___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Rational Rose
Em Qui, 2007-06-21 às 16:25 -0300, Placido Loko escreveu: Algum de vc's utilizam o Rational Rose? Gostaria de saber se alguem tem um tutorial apostila site ou documentação sobre o rose, pois gostaria de saber como gerar os codigos depois de criar o UML. UML não é adequado para modelagem. Por exemplo, não faz DOMAINs. -- Leandro Guimarães Faria Corcete DUTRA [EMAIL PROTECTED] Atech Fundação Aplicação de Tecnologias Críticas SP, BR msnim:[EMAIL PROTECTED] skype:leandro.gfc.dutra?chat +55 (11) 3040 7300 r151 - - - - - Politica de Privacidade: Esta mensagem pode conter informacao confidencial e/ou privilegiada. Se voce nao for o destinatario ou a pessoa autorizada a receber esta mensagem, nao pode usar, copiar ou divulgar as informacoes nela contidas ou tomar qualquer acao baseada nessas informacoes. Se voce recebeu esta mensagem por engano, por favor avise imediatamente o remetente, respondendo o e-mail e em seguida apague-o. Agradecemos sua cooperacao. Privacy Policy: This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Banco de dados Orientado a objeto
Em Qui, 2007-06-21 às 16:36 -0300, Andre Vargas escreveu: A possibilidade de se criar novos tipos de dados também é um recurso Objeto-Relacional, se não me engano. Só na propaganda. Não tem nada de especificamente OO em novos tipos de dados. -- Leandro Guimarães Faria Corcete DUTRA [EMAIL PROTECTED] Atech Fundação Aplicação de Tecnologias Críticas SP, BR msnim:[EMAIL PROTECTED] skype:leandro.gfc.dutra?chat +55 (11) 3040 7300 r151 - - - - - Politica de Privacidade: Esta mensagem pode conter informacao confidencial e/ou privilegiada. Se voce nao for o destinatario ou a pessoa autorizada a receber esta mensagem, nao pode usar, copiar ou divulgar as informacoes nela contidas ou tomar qualquer acao baseada nessas informacoes. Se voce recebeu esta mensagem por engano, por favor avise imediatamente o remetente, respondendo o e-mail e em seguida apague-o. Agradecemos sua cooperacao. Privacy Policy: This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] SELECT JOIN
Em Qui, 2007-06-21 às 14:31 -0300, Thiago Risso escreveu: Você vem de MySQL? Parece típico de MySQL, porque ele implementa subconsultas mal. Não ... É que já tive más experiencias com NOT IN... Onde o LEFT foi melhor, mas não me lembro exatamente a estrutura das tabelas nem índices... Bom, tem o EXISTS também, que creio ser ainda mais simples. Talvez versões antigas? Não parece haver grandes problemas com o otimizado nas v8. SELECT * FROM tzrepl.tzr_log L LEFT OUTER JOIN tzrepl.tzr_replicated_log RL ON RL.id_log = RL.id_log WHERE RL.id_log IS NULL; -- 861971 registros em 24078ms SELECT * FROM tzrepl.tzr_log L WHERE id_log NOT IN(SELECT id_log FROM tzrepl.tzr_replicated_log) --861971 registros em 19407ms Como eu suspeitava, você melhorou alguma coisa o plano de execução. Importa-se de publicá-lo na lista? Achei os números bem aceitáveis [1], principalmente por estar em um servidor de Teste (Bem ruinzinho por sinal)... Mas meu medo é que conforme esse registros aumentem (e vão aumentar muito), isto comece a ficar muito lento... Exato. Em produção eu utilizo também uma chave para filtrar os replicated_log, o que reduziria um pouco este número ( 718309 ) ... Estava pensando em colocar mais uma coluna (num_repl) em tzr_log, que seria incrementada a cada registro inserido em replicated_log e assim poderia adicionar mais uma condição ao select para tentar diminuir o SCAN (num_repl (select SUM(oid) FROM tzr_nodes) ... Isto é uma boa prática ?? O que sugerem ?? Não sei se entendi, mas não parece ser bom não… Concordo ..Mas existe como modelar de outra forma ?? Não creio. E se houver, tem de entender muito bem o problema para dar pitaco. Tenho uma tabela de nós (tzr_nodes), outra de log (tzr_log) e outra de logs replicados (tzr_replicated_log)... Nós 1:N replicated N:1 log? Quando eu insiro, altero ou deleto um registro insiro este na tabela de logs e replico este para o(s) nós que estão na tabela de nós e insiro um registro em logs replicados com o id do log e o id do nó para cada replicação que é efetuada com sucesso ... Ah, é você que está tentando implementar uma replicação na unha? Toda vez que aparece alguém com essa idéia eu aviso que é fria… não é o primeiro, e infelizmente não será o último. Vide a entrevista que o Telles publicou hoje. O melhor dos mundos seria, por exemplo, percorrer a tzr_log e, a partir de seu índice, o índice da tzr_replicated_log, evitando a tabela tzr_replicated_log em si. Existe como implementar isso ? Sim… se você tem os índices adequados, e não usa dados da replicated, mas apenas quer saber da existência ou não da chave indexada, deveria ser automático. Se não funcionar, talvez seja o caso de verificar com alguém mais esperto que eu, pode ser até um defeito de otimizador (duvido). -- Leandro Guimarães Faria Corcete DUTRA [EMAIL PROTECTED] Atech Fundação Aplicação de Tecnologias Críticas SP, BR msnim:[EMAIL PROTECTED] skype:leandro.gfc.dutra?chat +55 (11) 3040 7300 r151 - - - - - Politica de Privacidade: Esta mensagem pode conter informacao confidencial e/ou privilegiada. Se voce nao for o destinatario ou a pessoa autorizada a receber esta mensagem, nao pode usar, copiar ou divulgar as informacoes nela contidas ou tomar qualquer acao baseada nessas informacoes. Se voce recebeu esta mensagem por engano, por favor avise imediatamente o remetente, respondendo o e-mail e em seguida apague-o. Agradecemos sua cooperacao. Privacy Policy: This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation.___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Banco de dados Orientado a objeto
Em Qui, 2007-06-21 às 17:34 -0300, Andre Vargas escreveu: De fato não tem nada diretamente, mas a idéia de se romper com a 1a forma normal foi inspiração do pessoal do OO. Não exatamente. A 1ª forma normal é muito mal entendida. A idéia é mais separar os operadores relacionais dos operadores dos tipos; ela não restringe a complexidade dos tipos. Assim, o modelo relacional em si sempre suportou tipos de usuário. Afinal, o que são tipos mais domínios e seus operadores? Os produtos SQL (que não são relacionais) é que não suportam nada além dos tipos de sistema. -- Leandro Guimarães Faria Corcete DUTRA [EMAIL PROTECTED] Atech Fundação Aplicação de Tecnologias Críticas SP, BR msnim:[EMAIL PROTECTED] skype:leandro.gfc.dutra?chat +55 (11) 3040 7300 r151 - - - - - Politica de Privacidade: Esta mensagem pode conter informacao confidencial e/ou privilegiada. Se voce nao for o destinatario ou a pessoa autorizada a receber esta mensagem, nao pode usar, copiar ou divulgar as informacoes nela contidas ou tomar qualquer acao baseada nessas informacoes. Se voce recebeu esta mensagem por engano, por favor avise imediatamente o remetente, respondendo o e-mail e em seguida apague-o. Agradecemos sua cooperacao. Privacy Policy: This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation.___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Ferramentas de ‘Modelagem’
Vocês sabem que eu não gosto de ferramentas de diagramação, muito menos das que dizem que fazem modelagem. Na verdade, creio que com PostgreSQL não precisamos dessas ferramentas: vale mais a pena criar os domínios, depois as tabelas, e usar o AutoDoc ou mesmo o SQL Fairy para diagramar. Entretanto, estou na situação de ter de administrar os modelos de quatro diferentes SGBDs, e inúmeras bases de dados fragmentadas. Para isso, vou precisar de uma ferramenta de modelagem — não por causa dos diagramas, mas do dicionário de dados (basicamente). Estive investigando as ferramentas que suportam o PostgreSQL, conforme a famosa página http://postgresql.org.br./Ferramentas_para_o_PostgreSQL, para a qual também dei uma pequena contribuição. Mas queria jogar umas idéias aqui, e ver o que vocês acham. Em primeiro lugar, um dicionário de dados é fundamental. Isso já elimina várias ferramentas, como o DBWrench. As únicas que sobram capazes de rodar em GNU/Linux são o The Kompany Data Architect, que tem o básico (dicionário, relatórios, cobertura de vários SGBDs) mas dá um certo trabalho de instalar e configurar, usando acionadores ODBC, sendo um aplicativo Qt meio feioso e c; e o Druid III, bastante espartano e com problemas similares ao do Data Architect, mas em Java. O MySQL Workbench está em α já há coisa de um ano, e perdeu suporte ao PostgreSQL. Estranho. Há várias ferramentas MS Windows. A dificuldade com elas é ter de baixar trials, lidar com licenças, conseguir os contatos com os fornecedores. Até agora só consegui uma cotação da CA, porque minha empresa já tem relacionamento com eles. Nem Embarcadero, nem IBM (Data Architect) nem ninguém mais tem sido responsivo. Resumindo: há um campo enorme nessa área. Se alguém quiser pegar um projeto livre, como o MySQL Workbench ou o Druid, e desenvolver, será muito agradecido, desde que consiga deixar a diagramação de lado — deixe isso para AutoDoc ou SQL Fairy e concentre-se em dicionário de dados e relatórios. Dá vontade de criar scripts que exportem os modelos de cada SGBD, extraiam os tipos de dados e os carreguem numa base central. Mas o problema são as bases que não estão definidas com domínios — praticamente todas. Aliás, AutoDoc e SQL Fairy também precisam de colaboradores. O SQL Fairy não lida com muita sintaxe válida, como esquemas e comentários, por exemplo. O AutoDoc é bastante difícil de usar. Uma decepção de nota: as ferramentas UML (Argos, Telelogic System Architect c) não parecem dar conta do recado, por não suportarem dicionários de dados. Uma decepção para uma linguagem de modelagem que se queria universal. Falei bobagens, alguém tem informação a acrescentar? -- Leandro Guimarães Faria Corcete DUTRA [EMAIL PROTECTED] Atech Fundação Aplicação de Tecnologias Críticas SP, BR msnim:[EMAIL PROTECTED] skype:leandro.gfc.dutra?chat +55 (11) 3040 7300 r151 - - - - - Politica de Privacidade: Esta mensagem pode conter informacao confidencial e/ou privilegiada. Se voce nao for o destinatario ou a pessoa autorizada a receber esta mensagem, nao pode usar, copiar ou divulgar as informacoes nela contidas ou tomar qualquer acao baseada nessas informacoes. Se voce recebeu esta mensagem por engano, por favor avise imediatamente o remetente, respondendo o e-mail e em seguida apague-o. Agradecemos sua cooperacao. Privacy Policy: This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation.___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Compilação do PostgreSQL 8.1 para processamento simétrico
Em Qui, 2007-06-21 às 20:52 -0300, Euler Taveira de Oliveira escreveu: Leandro Guimaraes Faria Corcete DUTRA wrote: Se bem que o código com WITH, ao que me lembro, é mais chato de escrever e ler que o com CONNECT BY. A sintaxe do WITH é bizarra, mas é SQL... Então o pessoal decidiu (depois de várias discussões calorosas) _por coerência_ implementá-la. Sem contar que outros bancos como o DB2 também implementam. Tudo isso é verdade. Mas de vez em quando, faz sentido um padrão ‘de facto’. Como TCP/IP, por exemplo. -- Leandro Guimarães Faria Corcete DUTRA [EMAIL PROTECTED] Atech Fundação Aplicação de Tecnologias Críticas SP, BR msnim:[EMAIL PROTECTED] skype:leandro.gfc.dutra?chat +55 (11) 3040 7300 r151 - - - - - Politica de Privacidade: Esta mensagem pode conter informacao confidencial e/ou privilegiada. Se voce nao for o destinatario ou a pessoa autorizada a receber esta mensagem, nao pode usar, copiar ou divulgar as informacoes nela contidas ou tomar qualquer acao baseada nessas informacoes. Se voce recebeu esta mensagem por engano, por favor avise imediatamente o remetente, respondendo o e-mail e em seguida apague-o. Agradecemos sua cooperacao. Privacy Policy: This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation.___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] PROBLEMA COM UPDATE
Em Qua, 2007-06-20 às 10:19 -0300, Evandro (GMAIL) escreveu: BOM DIA PESSOAL Bom dia, mas por que gritas? TENHO UMA TABELA CHAMADA MENU COM AS SEGUINTES COLUNAS: menu_usuario CHAR(20) NOT NULL, menu_nivel1 NUMERIC(3,0) NOT NULL, menu_nivel2 NUMERIC(3,0) NOT NULL, menu_nivel3 NUMERIC(3,0) NOT NULL, menu_nivel4 NUMERIC(3,0) NOT NULL, Está parecendo erro de modelagem. Qual a idéia nesses níveis? PRECISO FAZER UM UPDATE PARA SUBIR O CAMPO MENU_NIVEL1 1 NÍVEL QUANDO USO O CÓDIGO ABAIXO, ELA DÁ ERRO DE CHAVE DUPLICADA UPDATE MENU SET MENU_NIVEL1 = (MENU_NIVEL1 -1) WHERE MENU_USUARIO = :MENU_USUARIO AND MENU_NIVEL1 :MENU_NIVEL1 ACONTECE QUE O UPDATE NÃO ESTA SEGUINDO A ORDEM DA CHAVE PRIMÁRIA Então coloque a chave como deferida. -- Leandro Guimarães Faria Corcete DUTRA [EMAIL PROTECTED] Atech Fundação Aplicação de Tecnologias Críticas SP, BR msnim:[EMAIL PROTECTED] skype:leandro.gfc.dutra?chat +55 (11) 3040 7300 r151 - - - - - Politica de Privacidade: Esta mensagem pode conter informacao confidencial e/ou privilegiada. Se voce nao for o destinatario ou a pessoa autorizada a receber esta mensagem, nao pode usar, copiar ou divulgar as informacoes nela contidas ou tomar qualquer acao baseada nessas informacoes. Se voce recebeu esta mensagem por engano, por favor avise imediatamente o remetente, respondendo o e-mail e em seguida apague-o. Agradecemos sua cooperacao. Privacy Policy: This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation.___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Compilação do PostgreSQL 8.1 para processamento simétrico
Em Qua, 2007-06-20 às 13:12 -0300, Welington R. Braga escreveu: O problema é a natureza deste tipo de aplicação exige uso de arvores. Sem problemas! Qual seria a melhor opção então, ou a sugestão de vocês sobre isso? A minha seria a do Pascal: duas relações, uma com os dados dos nós, outra com o relacionamento entre nós. Isso evita o auto-relacionamento, o NULL… -- Leandro Guimarães Faria Corcete DUTRA [EMAIL PROTECTED] Atech Fundação Aplicação de Tecnologias Críticas SP, BR msnim:[EMAIL PROTECTED] skype:leandro.gfc.dutra?chat +55 (11) 3040 7300 r151 - - - - - Politica de Privacidade: Esta mensagem pode conter informacao confidencial e/ou privilegiada. Se voce nao for o destinatario ou a pessoa autorizada a receber esta mensagem, nao pode usar, copiar ou divulgar as informacoes nela contidas ou tomar qualquer acao baseada nessas informacoes. Se voce recebeu esta mensagem por engano, por favor avise imediatamente o remetente, respondendo o e-mail e em seguida apague-o. Agradecemos sua cooperacao. Privacy Policy: This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation.___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Compilação do PostgreSQL 8.1 para processamento simétrico
Em Qua, 2007-06-20 às 17:23 -0300, Thiago Risso escreveu: Será que não seria algo assim [1] ... [1] http://www.sai.msu.su/~megera/postgres/gist/ltree/ Essa é uma alternativa, outra é o CONNECT BY, módulo do Contrib baseado no Oracle. O padrão seria o WITH do ISO. -- Leandro Guimarães Faria Corcete DUTRA [EMAIL PROTECTED] Atech Fundação Aplicação de Tecnologias Críticas SP, BR msnim:[EMAIL PROTECTED] skype:leandro.gfc.dutra?chat +55 (11) 3040 7300 r151 - - - - - Politica de Privacidade: Esta mensagem pode conter informacao confidencial e/ou privilegiada. Se voce nao for o destinatario ou a pessoa autorizada a receber esta mensagem, nao pode usar, copiar ou divulgar as informacoes nela contidas ou tomar qualquer acao baseada nessas informacoes. Se voce recebeu esta mensagem por engano, por favor avise imediatamente o remetente, respondendo o e-mail e em seguida apague-o. Agradecemos sua cooperacao. Privacy Policy: This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation.___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Compilação do PostgreSQL 8.1 para processamento simétrico
Em Qua, 2007-06-20 às 17:27 -0300, Welington R. Braga escreveu: Mas já é assim. Como eu disse no e-mail especificando o meu cenário: ...Pra simplificar o cenário, basicamente eu tenho duas tabelas (é muito mais do que isso, mas como eu disse é só pra simplificar). Dadas essas duas tabelas: Uma tem essa hierarquia, e a outra são dados da espécie em si Perfeito então, eu é que não li direito. Acho que foi o Euler (desculpe se não) quem falou em auto-relacionamento, e aí eu já assustei… Eu achei uma documentação interessante sobre dados hierarquicos na documentação do MySQL (http://dev.mysql.com/tech-resources/articles/hierarchical-data.html) Fraquinho… o primeiro é o famigerado auto-relacionamento, o segundo o terrível modelo do Celko. http://www.sitepoint.com/article/hierarchical-data-database/2 http://logbr.reflectivesurface.com/2003/12/17/armazendo-arvores-em-banco-de-dados/ http://www.intelligententerprise.com/001020/celko1_1.jhtml;jsessionid=NRVVJG3CR52DSQSNDLOSKHSCJUNN2JVN?_requestid=1193324 Não, o Celko não! O método dele é pura enrolação de embira! E todos esses aí são baseados nessa [EMAIL PROTECTED]@¨$%. -- Leandro Guimarães Faria Corcete DUTRA [EMAIL PROTECTED] Atech Fundação Aplicação de Tecnologias Críticas SP, BR msnim:[EMAIL PROTECTED] skype:leandro.gfc.dutra?chat +55 (11) 3040 7300 r151 - - - - - Politica de Privacidade: Esta mensagem pode conter informacao confidencial e/ou privilegiada. Se voce nao for o destinatario ou a pessoa autorizada a receber esta mensagem, nao pode usar, copiar ou divulgar as informacoes nela contidas ou tomar qualquer acao baseada nessas informacoes. Se voce recebeu esta mensagem por engano, por favor avise imediatamente o remetente, respondendo o e-mail e em seguida apague-o. Agradecemos sua cooperacao. Privacy Policy: This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation.___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Compilação do PostgreSQL 8.1 para processamento simétrico
Em Qua, 2007-06-20 às 18:08 -0300, Leandro Guimaraes Faria Corcete DUTRA escreveu: Em Qua, 2007-06-20 às 17:23 -0300, Thiago Risso escreveu: Será que não seria algo assim [1] ... [1] http://www.sai.msu.su/~megera/postgres/gist/ltree/ Essa é uma alternativa, outra é o CONNECT BY, módulo do Contrib baseado no Oracle. Aliás, desculpem a auto-resposta mas é uma alternativa de que não gostei muito: inclui dados redundantes, vide um trecho do código de amostra: create table dmoz ( id int, nametext, pathltree ); copy dmoz from stdin; 1 Top Top 2 Adult Top.Adult 3 BusinessTop.Adult.Business 4 Opportunities Top.Adult.Business.Opportunities 5 Home_Based Top.Adult.Business.Opportunities.Home_Based 6 InternetTop.Adult.Business.Opportunities.Internet -- Leandro Guimarães Faria Corcete DUTRA [EMAIL PROTECTED] Atech Fundação Aplicação de Tecnologias Críticas SP, BR msnim:[EMAIL PROTECTED] skype:leandro.gfc.dutra?chat +55 (11) 3040 7300 r151 - - - - - Politica de Privacidade: Esta mensagem pode conter informacao confidencial e/ou privilegiada. Se voce nao for o destinatario ou a pessoa autorizada a receber esta mensagem, nao pode usar, copiar ou divulgar as informacoes nela contidas ou tomar qualquer acao baseada nessas informacoes. Se voce recebeu esta mensagem por engano, por favor avise imediatamente o remetente, respondendo o e-mail e em seguida apague-o. Agradecemos sua cooperacao. Privacy Policy: This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation.___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
