Re: [pgbr-geral] Two Phase Commit
Imagine assim: Servidores A, B e C Comece a transação em cada um: A BEGIN; B BEGIN; C BEGIN; Faça alguma coisa em cada servidor: A INSERT INTO foo VALUES (1,2,3,4); B INSERT INTO foo VALUES (1,2,3,4); C INSERT INTO foo VALUES (1,2,3,4); Agora tente preparar as transações: A PREPARE TRANSACTION 'xpto'; B PREPARE TRANSACTION 'xpto'; C PREPARE TRANSACTION 'xpto'; A sua aplicação deve ter ciência que os três PREPARE acima deram certo. Se *todos* derem certo: A COMMIT PREPARED 'xpto'; B COMMIT PREPARED 'xpto'; C COMMIT PREPARED 'xpto'; Terminou. Agora vamos simular um erro no servidor B, se o PREPARE TRANSACTION falhar no B, você deverá fazer: A ROLLBACK PREPARED 'xpto'; C ROLLBACK PREPARED 'xpto'; E emitir um erro para seu usuário. Feito. PREPARE TRANSACTION é totalmente ACID, ou seja, atômico, garantido e persistente. Imagine que na hora do COMMIT, um dos servidores falhe! você pode fazer o COMMIT depois que esse servidor voltar, pois o PREPARE TRANSACTION já garantiu isso de forma persistente, em disco. Cuide apenas para que nenhum dos PREPARE TRANSACTION fique sem seu respectivo COMMIT ou ROLLBACK. Muito Obrigado! Rogério A Bassete ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Two Phase Commit
Utilize a função pg_prepared_xact() em seus servidores para verificar quais possuem transações pendentes. momento-propaganda Assista minha palestra no PGBR2011 para mais informações sobre funções úteis do servidor. /momento-propaganda Pode deixar Leo. []´s Rogério A Bassete ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Configurando Timezones por databases
Em 13/10/2011 23:21, Leandro Guimarães Faria Corce DUTRA escreveu: Le 2011-O-13 18h5, Flávio Alves Granato a écrit : Onde se encaixa o modelo não relacional nesta teoria? O famoso NoSQL, agora viu que não disse programação OO. Sim, acho que não é necessário implementar a complexidade de um modelo relacional em todas as situaçãos, apesar de ele poder ser usado. Acho que estou lesado, não entendi… o modelo relacional é mais simples, a complexidade fica toda dentro dos tipos… Opinião de cada um. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Configurando Timezones por databases
2011/10/14 Flávio Alves Granato flavio.gran...@gmail.com: Acho que estou lesado, não entendi… o modelo relacional é mais simples, a complexidade fica toda dentro dos tipos… Opinião de cada um. Absolutamente não. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Configurando Timezones por databases
Em 14/10/2011 10:33, Guimarães Faria Corcete DUTRA, Leandro escreveu: 2011/10/14 Flávio Alves Granatoflavio.gran...@gmail.com: Acho que estou lesado, não entendi… o modelo relacional é mais simples, a complexidade fica toda dentro dos tipos… Opinião de cada um. Absolutamente não. Onde o modelo relacional é mais simples que o NoSQL como comentei? === Sem flames senhores, pois sei que o Leandro responderá ponderadamente. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Função Update or Insert
Em 13 de outubro de 2011 18:43, desenvolvedor@gmail.com escreveu: Alexandre, poderia citar os malefícios das chaves artificiais? Supondo que você esteja se referindo a mim (Alexsander), o problema é o uso indiscriminado de chaves artificiais. Por exemplo, uma tabela de CEP não precisa ter uma coluna id_cep como PK, o próprio CEP é uma PK melhor. Neste caso, para saber o CEP de um logradouro é preciso um JOIN a mais. Outro exemplo: porque usar id_sexo numeric se podemos usar simplesmente sexo char(1) com um CHECK para garantir que seja M ou F? Muita gente usa ID em toda a base, de ponta a ponta, e isso é ruim. -- Atenciosamente, Alexsander da Rosa http://rednaxel.com ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Configurando Timezones por databases
2011/10/14 Flávio Alves Granato flavio.gran...@gmail.com: Onde o modelo relacional é mais simples que o NoSQL como comentei? Não existe um modelo NoSQL, ele é simplesmente a reversão às bases de dados prerrelacionais, dos anos sessenta e setenta. Isso dito, o modelo relacional trabalha com tipos, que equivalem às classes de OO e encapsulam a complexidade. O que o modelo relacional acrescenta são as relações (vulgo tabelas, desde que tenham ao menos uma chave natural declarada), que representam conjuntos de predicados (afirmações sobre o mundo real). Já NoSQL não tem nenhuma abstração, como todas as vezes que essa abordagem foi proposta antes, com outros nomes — redes, grafos, hierarquias, BDOO e vai por aí afora — tem‐se de criar um modelo específico para cada uso, sem nenhuma organização lógica. Parece mais simples ao pensar‐se somente nesse uso, mas por falta de abstrações e de independência de dados em relação à organização física, a complexidade vai se acumulando até inviabilizar a escalabilidade e (ou) a extensão do uso. Vide que, nesta atual moda NoSQL, os poucos casos de sucesso são ou extremamente restritos funcionalmente, ou contam com uma qualidade excepcional de programadores e SysAdmins para fazer funcionar, como é notoriamente o caso do Google. Mas o Google faz até o MySQL funcionar… enquanto os casos de fracasso sucedem‐se um após o outro. Ademais, vide o que SQL tem sido usado como abstração lógica para implementações normalmente associadas ao NoSQL, como é o caso do Yahoo! Himalaya (se não me falha a memória), agora o serviço MySQL do Google, e o MS SQL Server com Hadoop da MS. E temos os nossos próprios exemplos, se não me engano HadoopDB, Greenplum e um outro que me foge à memória. Quem escreveu bem a respeito foi o criador do Postgres http://en.wikipedia.org/wiki/Michael_Stonebraker#cite_note-10. Quanto à ilusão do ORM, o nosso David Fetter http://people.planetpostgresql.org/dfetter/index.php?/archives/40-Removing-Much-of-the-Suck-from-ORMs.html http://thoughts.j-davis.com/2007/12/03/on-orms-and-impedence-mismatch/. Quanto a outras discussões que deixo pendentes (lembro de duas), é de propósito: chegaram a um nível de animosidade e repetitividade que precisa mais tempo do que disponho para dar respostas que evitem a repetição do que aconteceu agora, dos meus argumentos serem ignorados por quem ainda não entendeu o modelo relacional nem parece querer entender, se preocupando antes em ganhar a discussão a qualquer custo… ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Configurando Timezones por databases
Em 14/10/2011 12:44, Guimarães Faria Corcete DUTRA, Leandro escreveu: 2011/10/14 Flávio Alves Granatoflavio.gran...@gmail.com: Onde o modelo relacional é mais simples que o NoSQL como comentei? Não existe um modelo NoSQL, ele é simplesmente a reversão às bases de dados prerrelacionais, dos anos sessenta e setenta. Isso dito, o modelo relacional trabalha com tipos, que equivalem às classes de OO e encapsulam a complexidade. O que o modelo relacional acrescenta são as relações (vulgo tabelas, desde que tenham ao menos uma chave natural declarada), que representam conjuntos de predicados (afirmações sobre o mundo real). Um SGBD como o PostgreSQL trabalha bem com um mundo não relacional? A gente vê alguns projetos grandes partindo para o lado NoSQL, cita algumas razões para estes projetos darem certo mais abaixo. Já NoSQL não tem nenhuma abstração, como todas as vezes que essa abordagem foi proposta antes, com outros nomes — redes, grafos, hierarquias, BDOO e vai por aí afora — tem‐se de criar um modelo específico para cada uso, sem nenhuma organização lógica. Parece mais simples ao pensar‐se somente nesse uso, mas por falta de abstrações e de independência de dados em relação à organização física, a complexidade vai se acumulando até inviabilizar a escalabilidade e (ou) a extensão do uso. hummm... não concordo a escalabilidade, mas concordo com a extensão do uso. Se bem que os casos em que vi troca de um SGBD por um NoSQL foi de MySQL para algum NoSQL. Realmente o MySQL precisa evoluir mais para acompanhar seus pares SGBD como o PostgreSQL Vide que, nesta atual moda NoSQL, os poucos casos de sucesso são ou extremamente restritos funcionalmente, ou contam com uma qualidade excepcional de programadores e SysAdmins para fazer funcionar, como é notoriamente o caso do Google. Mas o Google faz até o MySQL funcionar… enquanto os casos de fracasso sucedem‐se um após o outro. concordo, mas não conheço um caso de fracasso e arrependimento do uso de NoSQL, claro que fracassos não são tão divulgados quanto casos de sucesso, mas... Ademais, vide o que SQL tem sido usado como abstração lógica para implementações normalmente associadas ao NoSQL, como é o caso do Yahoo! Himalaya (se não me falha a memória), agora o serviço MySQL do Google, e o MS SQL Server com Hadoop da MS. E temos os nossos próprios exemplos, se não me engano HadoopDB, Greenplum e um outro que me foge à memória. Sem chance, uma coisa é uma coisa e outra coisa é outra coisa. Aquele velho ditado cada macaco no seu galho, vai ser mais um caso de bagunça para você alardear por ai e beatificar o modelo relacional. Quem escreveu bem a respeito foi o criador do Postgres http://en.wikipedia.org/wiki/Michael_Stonebraker#cite_note-10. Quanto à ilusão do ORM, o nosso David Fetter http://people.planetpostgresql.org/dfetter/index.php?/archives/40-Removing-Much-of-the-Suck-from-ORMs.html http://thoughts.j-davis.com/2007/12/03/on-orms-and-impedence-mismatch/. Quanto a outras discussões que deixo pendentes (lembro de duas), é de propósito: chegaram a um nível de animosidade e repetitividade que precisa mais tempo do que disponho para dar respostas que evitem a repetição do que aconteceu agora, dos meus argumentos serem ignorados por quem ainda não entendeu o modelo relacional nem parece querer entender, se preocupando antes em ganhar a discussão a qualquer custo… Como diria Maria para o Joãozinho, à força não hehehe ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] NoSQL (era: Configurando Timezones por databases)
2011/10/14 Flávio Alves Granato flavio.gran...@gmail.com: Um SGBD como o PostgreSQL trabalha bem com um mundo não relacional? E como não? Para começar, temos a extensibilidade de tipos — literalmente qualquer informação pode ser armazenada, com o CREATE TYPE. Depois, temos o DBI::Links já há alguns anos, que faz interface com tudo que se possa imaginar com a estrutura de DBDs e DBIs do Perl, e agora seu sucessor, o SQL/Med http://www.postgresql.org/docs/9.1/interactive/sql-createforeigndatawrapper.html http://www.postgresql.org/docs/9.1/interactive/sql-createserver.html. Por exemplo, mesmo o SQL/Med tendo acabado de ser implementado, já temos interfaces NoSQL http://wiki.postgresql.org/wiki/Foreign_data_wrappers#NoSQL_Databases_Wrappers e outras http://wiki.postgresql.org/wiki/Foreign_data_wrappers#File_Wrappers. A gente vê alguns projetos grandes partindo para o lado NoSQL, cita algumas razões para estes projetos darem certo mais abaixo. E muitos voltando… o Etsy foi um exemplo. Outros deram errado, se não me engano o Twitter foi um. concordo, mas não conheço um caso de fracasso e arrependimento do uso de NoSQL, claro que fracassos não são tão divulgados quanto casos de sucesso, mas... Etsy, Twitter, creio que outros da lista devem ter outros exemplos. Ademais, vide o que SQL tem sido usado como abstração lógica para implementações normalmente associadas ao NoSQL, como é o caso do Yahoo! Himalaya (se não me falha a memória), agora o serviço MySQL do Google, e o MS SQL Server com Hadoop da MS. E temos os nossos próprios exemplos, se não me engano HadoopDB, Greenplum e um outro que me foge à memória. Sem chance, uma coisa é uma coisa e outra coisa é outra coisa. Aquele velho ditado cada macaco no seu galho, vai ser mais um caso de bagunça para você alardear por ai e beatificar o modelo relacional. Não entendi a reação emotiva. O Yahoo! Himalaya já está em produção há tempos, os outros são também casos sólidos. Qual o problema? Como suspeitava, o problema é que você ainda não entendeu que o modelo relacional é lógico, abstrato, não físico; enquanto o NoSQL é físico, não lógico nem abstrato. Portanto, nada mais natural que usar técnicas associadas a NoSQL (e a seus antecessores) como métodos de armazenamento e busca de dados para SGBDs SQL ou relacionais. Assim como é o caso com OO, NoSQL na verdade são técnicas ortogonais ao modelo relacional. O problema é não perceber isso e tentar substituir o modelo relacional, lógico e abstrato, por técnicas que não são nem lógicas, nem abstratas. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] NoSQL (era: Configurando Timezones por databases)
Em 14/10/2011 13:31, Guimarães Faria Corcete DUTRA, Leandro escreveu: 2011/10/14 Flávio Alves Granatoflavio.gran...@gmail.com: Um SGBD como o PostgreSQL trabalha bem com um mundo não relacional? E como não? Para começar, temos a extensibilidade de tipos — literalmente qualquer informação pode ser armazenada, com o CREATE TYPE. interessante, mas ainda me parece melhor a forma como um mongodb trabalha com os tipos. Ademais, vide o que SQL tem sido usado como abstração lógica para implementações normalmente associadas ao NoSQL, como é o caso do Yahoo! Himalaya (se não me falha a memória), agora o serviço MySQL do Google, e o MS SQL Server com Hadoop da MS. E temos os nossos próprios exemplos, se não me engano HadoopDB, Greenplum e um outro que me foge à memória. Sem chance, uma coisa é uma coisa e outra coisa é outra coisa. Aquele velho ditado cada macaco no seu galho, vai ser mais um caso de bagunça para você alardear por ai e beatificar o modelo relacional. Não entendi a reação emotiva. O Yahoo! Himalaya já está em produção há tempos, os outros são também casos sólidos. Qual o problema? não foi uma reação puramente emotiva, foi mais uma brincadeira que uma reação negativa. Talvez você não entendeu o contexto da brincadeira e interpretou mal. Como suspeitava, o problema é que você ainda não entendeu que o modelo relacional... entendo parte, acho que você ainda não percebeu que quem vem com estes tipos de questionamentos não entende perfeitamente nenhum dos dois mundos. Mas procuro me aperfeiçoar e aprender, tanto que questiono e não imponho meus pensamentos. Não precisa suspeitar e nem julgar que quem vai discutir algo com você seja um doutorado no assunto, senão não seria discussão seria concordâncias. ...é lógico, abstrato, não físico; enquanto o NoSQL é físico, não lógico nem abstrato. Portanto, nada mais natural que usar técnicas associadas a NoSQL (e a seus antecessores) como métodos de armazenamento e busca de dados para SGBDs SQL ou relacionais. entendo. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] NoSQL (era: Configurando Timezones por databases)
Em 14/10/2011 13:31, Guimarães Faria Corcete DUTRA, Leandro escreveu: concordo, mas não conheço um caso de fracasso e arrependimento do uso de NoSQL, claro que fracassos não são tão divulgados quanto casos de sucesso, mas... Etsy, Twitter, creio que outros da lista devem ter outros exemplos. não acho material destes casos, twitter e Etsy. http://codeascraft.etsy.com/2010/05/19/mongodb-at-etsy/ só achei este link. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] NoSQL (era: Configurando Timezones por databases)
2011/10/14 Flávio Alves Granato flavio.gran...@gmail.com: Em 14/10/2011 13:31, Guimarães Faria Corcete DUTRA, Leandro escreveu: E como não? Para começar, temos a extensibilidade de tipos — literalmente qualquer informação pode ser armazenada, com o CREATE TYPE. interessante, mas ainda me parece melhor a forma como um mongodb trabalha com os tipos. A saber? De qualquer maneira, essa vantagem compensa todas as outras limitações? Ainda espero que venha a poder definir tipos em linguagens como SQL/PSM ou as interpretadas, mas já é extremamente poderoso. Sem chance, uma coisa é uma coisa e outra coisa é outra coisa. Aquele velho ditado cada macaco no seu galho, vai ser mais um caso de bagunça para você alardear por ai e beatificar o modelo relacional. Não entendi a reação emotiva. O Yahoo! Himalaya já está em produção há tempos, os outros são também casos sólidos. Qual o problema? não foi uma reação puramente emotiva, foi mais uma brincadeira que uma reação negativa. Talvez você não entendeu o contexto da brincadeira e interpretou mal. Realmente não entendi, foi uma ironia? Desculpa o Asperger http://pt.wikipedia.org/wiki/S%C3%ADndrome_de_Asperger aqui… ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] NoSQL (era: Configurando Timezones por databases)
Em 14/10/2011 13:55, Guimarães Faria Corcete DUTRA, Leandro escreveu: 2011/10/14 Flávio Alves Granatoflavio.gran...@gmail.com: Em 14/10/2011 13:31, Guimarães Faria Corcete DUTRA, Leandro escreveu: E como não? Para começar, temos a extensibilidade de tipos — literalmente qualquer informação pode ser armazenada, com o CREATE TYPE. interessante, mas ainda me parece melhor a forma como um mongodb trabalha com os tipos. A saber? De qualquer maneira, essa vantagem compensa todas as outras limitações? Ainda espero que venha a poder definir tipos em linguagens como SQL/PSM ou as interpretadas, mas já é extremamente poderoso. poiseh. Por isso eu disse que cada macado no seu galho. Cada ferramenta faz uma coisa diferente e para o que foi desenhada fazer, conhecer as teorias é uma coisa, agora saber aplicar seu uso é a diferença, você usuaria mesmo que limitado, independente de ser extremamente poderoso este SQL/PSM ao invés de uma ferramenta mais apropriada ou mesmo mais completa? Se sim, pode ser um arcabouço ou não. Mas já agregar valor ao produto não é válido? Quando asperger que conheço, pois tenho uma alta pontução para tal. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] NoSQL (era: Configurando Timezones por databases)
Em 14-10-2011 13:31, Guimarães Faria Corcete DUTRA, Leandro escreveu: E muitos voltando… o Etsy foi um exemplo. Outros deram errado, se não me engano o Twitter foi um. Twitter foi um que precisou migrar do modelo relacional para não parar. Ele agora usa Apache Cassandra. concordo, mas não conheço um caso de fracasso e arrependimento do uso de NoSQL, claro que fracassos não são tão divulgados quanto casos de sucesso, mas... Etsy, Twitter, creio que outros da lista devem ter outros exemplos. Nenhum destes na verdade, eu quase não vi ninguém que precisasse realmente de escalabilidade que fosse para o NoSql e tivese voltado. Mas vi, colegas, que quiseram seguir modinha para parecerem mais cool e aí sim, tiveram problemas. Abraço, -- Shander Lyrio http://about.me/shander ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] NoSQL (era: Configurando Timezones por databases)
2011/10/14 Flávio Alves Granato flavio.gran...@gmail.com: Em 14/10/2011 13:31, Guimarães Faria Corcete DUTRA, Leandro escreveu: concordo, mas não conheço um caso de fracasso e arrependimento do uso de NoSQL, claro que fracassos não são tão divulgados quanto casos de sucesso, mas... Etsy, Twitter, creio que outros da lista devem ter outros exemplos. não acho material destes casos, twitter e Etsy. O caso do Etsy http://hackerne.ws/item?id=3066286 é meio triste, porque eles começaram bem, com PostgreSQL, mas em vez de evoluir a arquitetura com os recursos do PostgreSQL e compatíveis, dançaram feio com MongoDB e agora parece que dançarão de novo com MySQL — poderia dar certo, como prova o Google, mas não parece que têm competência para isso. Já o Twitter é mais sutil http://highscalability.com/blog/2010/7/11/so-why-is-twitter-really-not-using-cassandra-to-store-tweets.html, disseram que iam para Cassandra e depois foram só em parte. O interessante nesses casos é ver gente batendo a cabeça por falta de conhecimento, e ainda assim ganhando muito dinheiro. O que explica porque até hoje não temos um SGBDR de verdade. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] NoSQL (era: Configurando Timezones por databases)
2011/10/14 Flávio Alves Granato flavio.gran...@gmail.com: Ainda espero que venha a poder definir tipos em linguagens como SQL/PSM ou as interpretadas, mas já é extremamente poderoso. poiseh. Por isso eu disse que cada macado no seu galho. Cada ferramenta faz uma coisa diferente e para o que foi desenhada fazer, conhecer as teorias é uma coisa, agora saber aplicar seu uso é a diferença, você usuaria mesmo que limitado, independente de ser extremamente poderoso este SQL/PSM ao invés de uma ferramenta mais apropriada ou mesmo mais completa? Se sim, pode ser um arcabouço ou não. Mas já agregar valor ao produto não é válido? Continuo sem entender… tu não respondeste que vantagens teria o MongoDB, e parece não ter entendido a extensibilidade de tipos do PostgreSQL, o que explicaria o comentário fora de contexto sobre o SQL/PSM. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Função Update or Insert
2011/10/14 Alexsander Rosa alexsander.r...@gmail.com Em 13 de outubro de 2011 18:43, desenvolvedor@gmail.com escreveu: Alexandre, poderia citar os malefícios das chaves artificiais? Supondo que você esteja se referindo a mim (Alexsander), o problema é o uso indiscriminado de chaves artificiais. Por exemplo, uma tabela de CEP não precisa ter uma coluna id_cep como PK, o próprio CEP é uma PK melhor. Neste caso, para saber o CEP de um logradouro é preciso um JOIN a mais. Outro exemplo: porque usar id_sexo numeric se podemos usar simplesmente sexo char(1) com um CHECK para garantir que seja M ou F? Muita gente usa ID em toda a base, de ponta a ponta, e isso é ruim. -- Atenciosamente, Alexsander da Rosa http://rednaxel.com ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral Voce citou um bom exemplo, no caso de CEP cidade onde o cep pode repetir até 2 vezes ou mais. Exemplo: Rua Pio XII CentroMairiporãSP0760 Rua XV de NovembroCentroMairiporãSP0760 Vou cirar um outro exemplo calssico, Nota Fiscal, qdo a NF chegar a 999.999 ela volta ao 1 e muda a série, quem coloca NF como PK ja esta cometendo um erro, o ideal seria NF+DataEmissão ou NF+Serie Na minha opnião tem que ter muito cuidado com relação a chaves etc. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] NoSQL (era: Configurando Timezones por databases)
2011/10/14 Shander Lyrio shan...@nucleo45.com.br: Em 14-10-2011 13:31, Guimarães Faria Corcete DUTRA, Leandro escreveu: E muitos voltando… o Etsy foi um exemplo. Outros deram errado, se não me engano o Twitter foi um. Twitter foi um que precisou migrar do modelo relacional para não parar. Não é verdade. O problema do Twitter foi com o MySQL, não com o modelo relacional. Ele agora usa Apache Cassandra. Apenas parcialmente, e continua parando… Etsy, Twitter, creio que outros da lista devem ter outros exemplos. Nenhum destes na verdade, eu quase não vi ninguém que precisasse realmente de escalabilidade que fosse para o NoSql e tivese voltado. Mas vi, colegas, que quiseram seguir modinha para parecerem mais cool e aí sim, tiveram problemas. Acho que não leste os detalhes, pelo menos não do Etsy. Há outros casos. De qualquer maneira, dá para escalar com NoSQL, sim; mas é muito doloroso, muito caro, e na maioria dos casos dá para fazer melhor e mais simples com PostgreSQL. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Função Update or Insert
2011/10/14 Charles Viana charles.vi...@gmail.com: Voce citou um bom exemplo, no caso de CEP cidade onde o cep pode repetir até 2 vezes ou mais. Exemplo: Rua Pio XII Centro Mairiporã SP 0760 Rua XV de Novembro Centro Mairiporã SP 0760 Mas aí é uma tabela de endereços, não de CEPs. Vou cirar um outro exemplo calssico, Nota Fiscal, qdo a NF chegar a 999.999 ela volta ao 1 e muda a série, quem coloca NF como PK ja esta cometendo um erro, o ideal seria NF+DataEmissão ou NF+Serie Normal, uma chave composta é tranqüilo. Na minha opnião tem que ter muito cuidado com relação a chaves etc. E que cuidados recomendarias? ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Função Update or Insert
Em 14 de outubro de 2011 14:25, Guimarães Faria Corcete DUTRA, Leandro l...@dutras.org escreveu: 2011/10/14 Charles Viana charles.vi...@gmail.com: Voce citou um bom exemplo, no caso de CEP cidade onde o cep pode repetir até 2 vezes ou mais. Exemplo: Rua Pio XII Centro Mairiporã SP 0760 Rua XV de Novembro Centro Mairiporã SP 0760 Mas aí é uma tabela de endereços, não de CEPs. Exato. No site dos Correios, se você pesquisar por 0760 vem apenas a cidade de Mairiporã. -- Atenciosamente, Alexsander da Rosa http://rednaxel.com ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Duvidas com Right Outer Join
From: marc...@ig.com.br
To: pgbr-geral@listas.postgresql.org.br
Date: Thu, 13 Oct 2011 11:07:23 -0300
Subject: [pgbr-geral] Duvidas com Right Outer Join
Pessoal mais uma vez preciso da vossa ajuda [Alegre]
Tenho o seguinte select
select distinct f.data_age, a.cod_key, a.cod_id, d.nome, d.end_abr,
d.end_cad, d.end_num, d.end_com, d.end_bai, d.end_cid, d.end_est,
end_cep, a.pedido, a.data_age, a.hora_age, a.hora_fim, a.codigo,
b.descricao, c.qtd_item, e.obs_tecnico, a.tipo, a.agendamento,
a.cod_ope, a.data_cad, a.obs, a.observacoes, a.obs_interna
from mv_vendas_pre_agenda a
inner join mv_produtos b on(b.codigo = a.codigo)
inner join mv_vendas_pre_itens c on(c.cod_id = a.cod_id)
and(c.pedido = a.pedido)
and(c.codigo = a.codigo)
and(c.obs not in('C'))
left join mv_vendas e on(e.cod_id = a.cod_id)
and(e.pedido = a.pedido)
inner join mv_clientes d on(d.cod_id = a.cod_id)
right join mv_vendas_pre_mes f on(f.data_age = a.data_age)
where (a.obs not in('C'))
and(b.tipo = 'M')
and((a.data_age is null)or(a.data_age = '01/10/2011'))
order by a.data_age, a.hora_age, a.cod_id
Desculpe colocar o select todo, mas acho que fica melhor a compreensão
A ideia é que a tabelas mv_vendas_pre_mes ( F ) tem registros que não
tem na tabela ( A )
Mas preciso trazer essas datas justamente pra mostrar que não existem
agendamentos naquele dia.
Imagino que o Right Join deveria trazer todos os registros da tabela (
F ) mesmo não contendo a referncia, mas não é isso que ocorre.
Não estou compreendendo esse Right
Eu preciso que a tabela ( A ) seja a tabela principal do select
Olá Marcelo,
Como você não usou parênteses nos seus joins, a ordem de junção será da
esquerda para direita (conforme [1]).
Seguindo a ordem do seu select, as junções ficariam da seguinte forma:
((mv_vendas_pre_agenda+mv_produtos+mv_vendas_pre_itens-mv_vendas)+mv_clientes)-mv_vendas_pre_mes
Neste caso, serão mostrados todos os registros da tabela
mv_vendas_pre_mes(direita do right join), e quando tiver relacionamentos,
mostrará o resultado dos outros joins, senão mostrará null. Aí a tabela
principal fica sendo a F.
[1]http://www.postgresql.org/docs/9.0/static/sql-select.html
Atenciosamente,
Marçal de Lima Hokamaattachment: wlEmoticon-smile[1].png___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Função Update or Insert
From: l...@dutras.org Date: Fri, 14 Oct 2011 14:25:13 -0300 To: pgbr-geral@listas.postgresql.org.br Subject: Re: [pgbr-geral] Função Update or Insert 2011/10/14 Charles Viana charles.vi...@gmail.com: Voce citou um bom exemplo, no caso de CEP cidade onde o cep pode repetir até 2 vezes ou mais. Exemplo: Rua Pio XII CentroMairiporãSP0760 Rua XV de NovembroCentroMairiporãSP0760 Mas aí é uma tabela de endereços, não de CEPs. Exato. Na tabela de CEPs cada CEP é único. O que não se pode confundir é a relação entre CEP e logradouro, onde um único CEP pode ser referenciado por mais de um logradouro (como mostrado acima), no caso de CEPs com sufixo 000 em algumas localidades (vide [1]). [1] http://www.correios.com.br/servicos/cep/cep_estrutura.cfm Atenciosamente, Marçal de Lima Hokama ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Modelagem (era: Função Update or Insert)
2011/10/14 Marcal Hokama mhok...@hotmail.com: From: l...@dutras.org Mas aí é uma tabela de endereços, não de CEPs. Exato. Na tabela de CEPs cada CEP é único. O que não se pode confundir é a relação entre CEP e logradouro, onde um único CEP pode ser referenciado por mais de um logradouro (como mostrado acima), no caso de CEPs com sufixo 000 em algumas localidades (vide [1]). Ou seja, poderíamos dizer que é CEP n:m logradouros, certo? ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Select Numerando Registros?
Pessoal, é possível fazer um select onde ele numera os registros trazidos? Exemplo: select sequencia, * from clientes Ou seja na primeira coluna gostaria de trazer 1,2,3,4... Só pra efeito de vizualizacao mesmo Marcelo Silva -- Desenvolvedor Delphi, PHP msn: marc...@ig.com.br cel.: (11) 9693-4251___ 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 Numerando Registros?
Em 14 de outubro de 2011 15:02, Marcelo Silva (IG) marc...@ig.com.br escreveu: Pessoal, é possível fazer um select onde ele numera os registros trazidos? Exemplo: select sequencia, * from clientes Ou seja na primeira coluna gostaria de trazer 1,2,3,4... Só pra efeito de vizualizacao mesmo Você não falou a versão do PostgreSQL, mas a partir da 8.4 você pode usar row_number() [1]. [1] http://www.postgresql.org/docs/current/interactive/functions-window.html -- Dickson S. Guedes mail/xmpp: gue...@guedesoft.net - skype: guediz http://guedesoft.net - http://www.postgresql.org.br ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Função Update or Insert
Em 14-10-2011 14:54, Marcal Hokama escreveu: Exato. Na tabela de CEPs cada CEP é único. O que não se pode confundir é a relação entre CEP e logradouro, onde um único CEP pode ser referenciado por mais de um logradouro (como mostrado acima), no caso de CEPs com sufixo 000 em algumas localidades (vide [1]). E o cep que está para um determinado endereço pode não ser o mesmo cep do ano que vem, notadamente nas cidades que tem sua população crescendo mais do que o previsto pelos correios. Novos ceps são criados, e velhos são substituídos sem que o antigo endereço tenha saído do lugar, reestruturações são feitas a todo o instante. Faixas de cep são divididas entre os estados, municípios, bairros, sub-regiões do bairro e essa subdivisão muda cada vez que é construída uma grande avenida ou algum extensão adjacente ao bairro. Eu tenho convivido com ceps a minha vida toda e tenho tentado acompanhar as mazelas dos correios, já que minha atividade princípua está no ramo de logística. O Cep não é uma entidade, nem chave natural de entidade alguma é apenas o atributo de um endereço. Primeiro, em cidades pequenas que tenham cep único, você não consegue dar um cep diferente para cada endereço, logo ele não identifica unicamente uma entidade endereço. Você também não pode usá-lo para ser chave natural de uma cidade, porque tem cidades que tem diversos ceps, analogamente não pode usar para estados, uma tabela de cep serve apenas como restrição se um cep é válido ou não e mesmo assim não serviria 100% já que um cep que é válido em um ano pode não ser válido no outro.. Uma tabela de cep's é apenas uma tabela cheia de dados em que o atributo cep é único e não se repete. Nada mais, um cep não pode ser usado como suficiente chave natural para identificar nada. Na prática, a teoria é outra coisa. -- Shander Lyrio ___ 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 Numerando Registros?
hum... Versao 8.4 Valeu Dickson -Mensagem Original- From: Dickson S. Guedes Sent: Friday, October 14, 2011 3:19 PM To: Marcelo Silva (IG) ; Comunidade PostgreSQL Brasileira Subject: Re: [pgbr-geral] Select Numerando Registros? Em 14 de outubro de 2011 15:02, Marcelo Silva (IG) marc...@ig.com.br escreveu: Pessoal, é possível fazer um select onde ele numera os registros trazidos? Exemplo: select sequencia, * from clientes Ou seja na primeira coluna gostaria de trazer 1,2,3,4... Só pra efeito de vizualizacao mesmo Você não falou a versão do PostgreSQL, mas a partir da 8.4 você pode usar row_number() [1]. [1] http://www.postgresql.org/docs/current/interactive/functions-window.html -- Dickson S. Guedes mail/xmpp: gue...@guedesoft.net - skype: guediz http://guedesoft.net - http://www.postgresql.org.br ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Chaves (era: Função Update or Insert)
2011/10/14 Shander Lyrio shan...@nucleo45.com.br: Uma tabela de cep's é apenas uma tabela cheia de dados em que o atributo cep é único e não se repete. Nada mais, um cep não pode ser usado como suficiente chave natural para identificar nada. E ninguém disse o contrário. O que se argumentou é que é contraproducente criar uma chave artificial quando já existe uma natural, por exemplo, CEP numa relação de CEPs. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] pg_dump X pg_dumpall
Pessoal, Eu sei que o pg_dump é executado para cada base de dados, enquanto o pg_dumpall é feito para todo o cluster e em testes que fiz o tempo entre os dois foi o mesmo, vocês poderiam dizer se existe outra diferença relevante? Em termos de segurança faz alguma diferença? Abs Danilo ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] NoSQL (era: Configurando Timezones por databases)
Em 14-10-2011 14:23, Guimarães Faria Corcete DUTRA, Leandro escreveu: Não é verdade. O problema do Twitter foi com o MySQL, não com o modelo relacional. O MySql é muito usado hoje porque notadamente escala melhor em enormes quantidades de requisições. Ele consegue isto sendo apenas um repositório de dados com o myisan que é muito menos rigoroso com relação ao que o modelo relacional exige: restrição de tipos não é levada a sério, nada de foreign keys, transações, etc... Ele agora usa Apache Cassandra. Apenas parcialmente, e continua parando… E se usasse PostGreSql? Como ele se comportaria com um pico de 1.6 bilhões de querys por dia? e picos de 18 mil tweets por segundo? Tente colocar um foreign key aí pra garantir integridade dos dados. Integridade para que? Se um twetter for perdido, lança-se outro e pronto. Sua confiança no Elefante e no modelo relacional é admirável, mas as vezes isso te cega. E o faz de tal forma que você não consegue perceber que toda a ferramenta foi feita para um propósito em mente e que o PostGreSql (eu gosto de caixa alta) não foi feito para resolver todos os problemas do mundo. Um último detalhe, os engenheiros do Twitter estão trabalhando em um novo sgdb NoSql [1] ainda mais leve que o Cassandra feito em Scala. Já está em produção inclusive e com uma performance incrível, e estou falando da performance que o twitter precisa, não a que você acha que ele precisa. Eu gostaria de ver o PostGreSql (sim, usei novamente a caixa propositalmente, eu gosto dela) escalando horizontalmente em centenas de servidores e servindo 100k leituras e 20k escritas por segundo. O que você tem de bom é conhecer bem o modelo relacional, o que tem de ruim é achar que ele é a solução para tudo, conhecer bem significa também saber suas limitações. [1] https://github.com/twitter/flockdb -- Shander Lyrio http://about.me/shander ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Chaves (era: Função Update or Insert)
Em 14-10-2011 15:31, Guimarães Faria Corcete DUTRA, Leandro escreveu: 2011/10/14 Shander Lyrioshan...@nucleo45.com.br: Uma tabela de cep's é apenas uma tabela cheia de dados em que o atributo cep é único e não se repete. Nada mais, um cep não pode ser usado como suficiente chave natural para identificar nada. E ninguém disse o contrário. O que se argumentou é que é contraproducente criar uma chave artificial quando já existe uma natural, por exemplo, CEP numa relação de CEPs. Você está falando de uma entidades cep com um único atributo cep tem como chave natural o cep? Uau, este é um belo exemplo da vida real. Nem é preciso apelar para teoria de conjuntos para mostrar o quanto isto é óbvio. Mas já que é para brincar sério, vamos lá. Procure nesta tabela o cep 69908992, você não vai achar nela se estiver utilizando a tabela de cep fornecida pelos correios, mas ele é um cep válido. Ceps de caixas postais terminam com os dígitos 990 à 998 e são usados ao gosto dos correios e mudados também, não estão na tabela de cep's a não ser que você tenha colocado todas estas combinações. Analogamente é possível mostrar que você precisaria ter todas as combinações de até para garantir abranger os possíveis cep's válidos. -- Shander Lyrio http://about.me/shander ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] pg_dump X pg_dumpall
2011/10/14 Danilo Silva danilo.dsg.go...@gmail.com: Eu sei que o pg_dump é executado para cada base de dados, enquanto o pg_dumpall é feito para todo o cluster e em testes que fiz o tempo entre os dois foi o mesmo, vocês poderiam dizer se existe outra diferença relevante? Em termos de segurança faz alguma diferença? Eu me sinto mais seguro com o pg_dumpall, mas pelo risco dalguma base ficar de fora ou falhar no caso de pg_dump base a base. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Função Update or Insert
Date: Fri, 14 Oct 2011 15:24:52 -0300 From: shan...@nucleo45.com.br To: pgbr-geral@listas.postgresql.org.br Subject: Re: [pgbr-geral] Função Update or Insert O Cep não é uma entidade, nem chave natural de entidade alguma é apenas o atributo de um endereço. Primeiro, em cidades pequenas que tenham cep único, você não consegue dar um cep diferente para cada endereço, logo ele não identifica unicamente uma entidade endereço. Você também não pode usá-lo para ser chave natural de uma cidade, porque tem cidades que tem diversos ceps, analogamente não pode usar para estados, uma tabela de cep serve apenas como restrição se um cep é válido ou não e mesmo assim não serviria 100% já que um cep que é válido em um ano pode não ser válido no outro.. Uma tabela de cep's é apenas uma tabela cheia de dados em que o atributo cep é único e não se repete. Nada mais, um cep não pode ser usado como suficiente chave natural para identificar nada. O CEP como atributo de um endereço, tem um domínio, ou conjunto pré-definido de valores que é a relação de CEPs gerenciada pelos Correios, que tem uma estrutura definida em [1]. Se fosse modelar com base nessas informações, uma relação de CEPs poderia ser tanto um domínio como uma entidade (dúvida sobre ser realmente uma entidade - mas na prática iria virar uma tabela mesmo). Na prática, a teoria é outra coisa. Realmente. Trabalho aqui com o CD do Diretório Nacional de Endereços dos Correios, que tenho que importar periodicamente para a nossa base, e na prática essa suposta tabela de CEPs vira uma estrutura bem mais complexa... [1] http://www.correios.com.br/servicos/cep/cep_estrutura.cfm Atenciosamente, Marçal de Lima Hokama ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] pg_dump X pg_dumpall
Mas eu consigo listar o conteúdo do arquivo dumpall pelo pg_restore utilizando o parâmetro --list? Pois assim seria possível efetuar o restore de apenas um banco específico. Att. Em 14 de outubro de 2011 15:51, Guimarães Faria Corcete DUTRA, Leandro l...@dutras.org escreveu: 2011/10/14 Danilo Silva danilo.dsg.go...@gmail.com: Eu sei que o pg_dump é executado para cada base de dados, enquanto o pg_dumpall é feito para todo o cluster e em testes que fiz o tempo entre os dois foi o mesmo, vocês poderiam dizer se existe outra diferença relevante? Em termos de segurança faz alguma diferença? Eu me sinto mais seguro com o pg_dumpall, mas pelo risco dalguma base ficar de fora ou falhar no caso de pg_dump base a base. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Modelagem (era: Função Update or Insert)
Em 14-10-2011 15:08, Guimarães Faria Corcete DUTRA, Leandro escreveu: 2011/10/14 Marcal Hokamamhok...@hotmail.com: From: l...@dutras.org Mas aí é uma tabela de endereços, não de CEPs. Exato. Na tabela de CEPs cada CEP é único. O que não se pode confundir é a relação entre CEP e logradouro, onde um único CEP pode ser referenciado por mais de um logradouro (como mostrado acima), no caso de CEPs com sufixo 000 em algumas localidades (vide [1]). Ou seja, poderíamos dizer que é CEP n:m logradouros, certo? Lindo na teoria e péssimo na prática. Um cep que termine com a faixa de 990 à 998 não está associada a um logradouro. Se quiser forçar a barra deste jeito você teria que ter relacionamentos n:m para caixas postais, bairros, logradouros, cidades, estados, além de grandes usuários e cep's promocionais que são usados ao gosto dos correios. Você acha que isto é usável? -- Shander Lyrio http://about.me/shander ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Modelagem (era: Função Update or Insert)
Em 14 de outubro de 2011 15:58, Shander Lyrio shan...@nucleo45.com.br escreveu: Em 14-10-2011 15:08, Guimarães Faria Corcete DUTRA, Leandro escreveu: 2011/10/14 Marcal Hokamamhok...@hotmail.com: From: l...@dutras.org Mas aí é uma tabela de endereços, não de CEPs. Exato. Na tabela de CEPs cada CEP é único. O que não se pode confundir é a relação entre CEP e logradouro, onde um único CEP pode ser referenciado por mais de um logradouro (como mostrado acima), no caso de CEPs com sufixo 000 em algumas localidades (vide [1]). Ou seja, poderíamos dizer que é CEP n:m logradouros, certo? Lindo na teoria e péssimo na prática. Um cep que termine com a faixa de 990 à 998 não está associada a um logradouro. Se quiser forçar a barra deste jeito você teria que ter relacionamentos n:m para caixas postais, bairros, logradouros, cidades, estados, além de grandes usuários e cep's promocionais que são usados ao gosto dos correios. Você acha que isto é usável? A tabela de CEP tem a grande utilidade de padronizar dados. Não se trata de armazenar um endereço como CEP mais alguma coisa, mas sim usar a tabela de CEPs para PREENCHER o endereço corretamente. Sem isso, uma rua com a palavra WASHINGTON acabaria sendo cadastrada com diversas grafias. O mesmo vale para os bairros: aqui em Porto Alegre tem um bairro chamado MONT SERRAT que, sem um cadastro de CEP (ou equivalente), seria preenchido de diversas maneiras criativas pelos usuários. -- Atenciosamente, Alexsander da Rosa http://rednaxel.com ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Função Update or Insert
Em 14-10-2011 15:53, Marcal Hokama escreveu: Uma tabela de cep's é apenas uma tabela cheia de dados em que o atributo cep é único e não se repete. Nada mais, um cep não pode ser usado como suficiente chave natural para identificar nada. O CEP como atributo de um endereço, tem um domínio, ou conjunto pré-definido de valores que é a relação de CEPs gerenciada pelos Correios, que tem uma estrutura definida em [1]. Se fosse modelar com base nessas informações, uma relação de CEPs poderia ser tanto um domínio como uma entidade (dúvida sobre ser realmente uma entidade - mas na prática iria virar uma tabela mesmo). Se os cep's não mudassem todo o ano eu até concordaria em dizer conjunto pré-definido, mas mudam. O que é um cep hoje, podem ser 2 amanhã, então nem adianta um on update cascade. Vejamos a situação, o atributo cep do endereço do cliente é uma foreign key para uma relação de ceps. No próximo ano os correios decidiram que este cep não existe mais, e agora? considerar cep como entidade te criaria um grande problema, porque derrepente, seu cliente passa a não ter mais cep ou a não ter um cep válido, ah, você tem uma restrição de integridade... então vá lá falar para os correios que eles não podem extinguir um cep. O que faremos?? Caso recente, a cidade em que eu nasci São Mateus-ES, tinha cep único 2993, já faz alguns anos que ele foi todo dividido porque a cidade cresceu, consulte o cep nos correios.. não existe mais. Mas até hoje, se você colocar o cep 2993 as encomendas chegam na casa dos meus pais certinho. Abraço, -- Shander Lyrio http://about.me/shander ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] NoSQL (era: Configurando Timezones por databases)
Date: Fri, 14 Oct 2011 15:39:12 -0300 From: shan...@nucleo45.com.br To: pgbr-geral@listas.postgresql.org.br Subject: Re: [pgbr-geral] NoSQL (era: Configurando Timezones por databases) Em 14-10-2011 14:23, Guimarães Faria Corcete DUTRA, Leandro escreveu: Não é verdade. O problema do Twitter foi com o MySQL, não com o modelo relacional. O MySql é muito usado hoje porque notadamente escala melhor em enormes quantidades de requisições. Ele consegue isto sendo apenas um repositório de dados com o myisan que é muito menos rigoroso com relação ao que o modelo relacional exige: restrição de tipos não é levada a sério, nada de foreign keys, transações, etc... O MySQL é o banco mais utilizado no mundo (e como foi comentado anteriormente, até a Google faz ele funcionar, hehehe), e mesmo após a compra da Oracle tem apresentado evoluções principalmente no storage engine InnoDB. Ele tem as suas virtudes. E se usasse PostGreSql? Como ele se comportaria com um pico de 1.6 bilhões de querys por dia? e picos de 18 mil tweets por segundo? Tente colocar um foreign key aí pra garantir integridade dos dados. Integridade para que? Se um twetter for perdido, lança-se outro e pronto. Sua confiança no Elefante e no modelo relacional é admirável, mas as vezes isso te cega. E o faz de tal forma que você não consegue perceber que toda a ferramenta foi feita para um propósito em mente e que o PostGreSql (eu gosto de caixa alta) não foi feito para resolver todos os problemas do mundo. Um último detalhe, os engenheiros do Twitter estão trabalhando em um novo sgdb NoSql [1] ainda mais leve que o Cassandra feito em Scala. Já está em produção inclusive e com uma performance incrível, e estou falando da performance que o twitter precisa, não a que você acha que ele precisa. Eu gostaria de ver o PostGreSql (sim, usei novamente a caixa propositalmente, eu gosto dela) escalando horizontalmente em centenas de servidores e servindo 100k leituras e 20k escritas por segundo. O que você tem de bom é conhecer bem o modelo relacional, o que tem de ruim é achar que ele é a solução para tudo, conhecer bem significa também saber suas limitações. [1] https://github.com/twitter/flockdb O PostgreSQL tem muitas qualidades e uma ampla gama de áreas de atuação, mas haverá situações em que teremos situações em que um determinadas funcionalidades serão sacrificadas em detrimento da performance ou outra característica em que outro banco de dados é superior. Depende muito de cada situação. Atenciosamente, Marçal de Lima Hokama ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] pg_dump X pg_dumpall
Em 14 de outubro de 2011 15:57, Danilo Silva danilo.dsg.go...@gmail.com escreveu: Mas eu consigo listar o conteúdo do arquivo dumpall pelo pg_restore utilizando o parâmetro --list? Pois assim seria possível efetuar o restore de apenas um banco específico. Não, a saida dele é SQL, ou seja ele chama internamente pg_dump --format=plain, o restore você faz via psql. Costumo utilizar o pg_dumpall apenas para ter um dump dos objetos globais, enquanto demais banco de dados do cluster são 'dumpeados' um a um com um pg_dump --format=custom. Mais detalhes em [1]. [1] http://www.postgresql.org/docs/current/static/app-pg-dumpall.html -- Dickson S. Guedes mail/xmpp: gue...@guedesoft.net - skype: guediz http://guedesoft.net - http://www.postgresql.org.br ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] pg_dump X pg_dumpall
Em 14 de outubro de 2011 16:21, Dickson S. Guedes lis...@guedesoft.net escreveu: Em 14 de outubro de 2011 15:57, Danilo Silva danilo.dsg.go...@gmail.com escreveu: Mas eu consigo listar o conteúdo do arquivo dumpall pelo pg_restore utilizando o parâmetro --list? Pois assim seria possível efetuar o restore de apenas um banco específico. Não, a saida dele é SQL, ou seja ele chama internamente pg_dump --format=plain, o restore você faz via psql. Apenas fazendo um adendo, caso você já tenha o arquivo nesse formato e realmente queira restaurar apenas um banco, você conseguiria gerar um arquivo de stage com um utilitário como o `sed` para extrair apenas a parte do arquivo que te interessa. Isso é possivel porque dentro do arquivo gerado pelo pg_dumpall você vê vários '\connect' e a partir dai você sabe para qual banco os comandos subsequentes são enviados, até que ele encontre um próximo '\connect' que dai já pertence a outro banco. -- Dickson S. Guedes mail/xmpp: gue...@guedesoft.net - skype: guediz http://guedesoft.net - http://www.postgresql.org.br ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] pg_dump X pg_dumpall
Foi o que eu imaginei, visto o a diferença no tamanho entre eles, mas tem como gerar o dump por base com o comando create database? para em alguma emergência somente executar o script e não ter que criar o banco antes, e se for possível, como seria o sintaxe do comando pg_restore? Agradeço a todos pela ajuda. Att Em 14 de outubro de 2011 16:21, Dickson S. Guedes lis...@guedesoft.netescreveu: Em 14 de outubro de 2011 15:57, Danilo Silva danilo.dsg.go...@gmail.com escreveu: Mas eu consigo listar o conteúdo do arquivo dumpall pelo pg_restore utilizando o parâmetro --list? Pois assim seria possível efetuar o restore de apenas um banco específico. Não, a saida dele é SQL, ou seja ele chama internamente pg_dump --format=plain, o restore você faz via psql. Costumo utilizar o pg_dumpall apenas para ter um dump dos objetos globais, enquanto demais banco de dados do cluster são 'dumpeados' um a um com um pg_dump --format=custom. Mais detalhes em [1]. [1] http://www.postgresql.org/docs/current/static/app-pg-dumpall.html -- Dickson S. Guedes mail/xmpp: gue...@guedesoft.net - skype: guediz http://guedesoft.net - http://www.postgresql.org.br ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Modelagem (era: Função Update or Insert)
Em 14-10-2011 16:05, Alexsander Rosa escreveu: Em 14 de outubro de 2011 15:58, Shander Lyrio A tabela de CEP tem a grande utilidade de padronizar dados. Não se trata de armazenar um endereço como CEP mais alguma coisa, mas sim usar a tabela de CEPs para PREENCHER o endereço corretamente. Sem isso, uma rua com a palavra WASHINGTON acabaria sendo cadastrada com diversas grafias. O mesmo vale para os bairros: aqui em Porto Alegre tem um bairro chamado MONT SERRAT que, sem um cadastro de CEP (ou equivalente), seria preenchido de diversas maneiras criativas pelos usuários. Entendo bem isso e utilizo, mas sempre deixo aberto para o meu cliente poder mudar, até porque ruas mudam de nome e bairros também. Meu cep hoje 29092170 antes estava como sendo bairro Santa Terezinha, mas um outro bairro cresceu muito e os correios resolveram juntar todo mundo. Hoje este cep é do bairro Jardim Camburi. A discussão é sobre o cep ser uma chave natural e eu estou tentando mostrar ele não é porque o significado dele muda toda a hora. Uma entidade com um único atributo faz com que ela se confunda com os valores atribuídos. Colocar M para Masculino e F para feminino é tão feio quanto 0 para Masculino e 1 para Feminino, porque em ambos os casos você criou um id para indicar o sexo, apenas mudou o tipo deste id. O fato de ser a primeira letra facilita a visualização do DBA, mas não aumenta ou reduz a complexidade das query's a não ser que você vá apresentar para o usuário final apenas a letra M ou F. -- Shander Lyrio http://about.me/shander ___ 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 Numerando Registros?
A cada dia que passa estou gostando mais desse Postgres :) Consegui o sequencial com o seguinte select (exemplo) select row_number() OVER (PARTITION by 0) as contador, cod_cli, nome from clientes Mais uma vez obrigado, p ppessoal -Mensagem Original- From: Dickson S. Guedes Sent: Friday, October 14, 2011 3:19 PM To: Marcelo Silva (IG) ; Comunidade PostgreSQL Brasileira Subject: Re: [pgbr-geral] Select Numerando Registros? Em 14 de outubro de 2011 15:02, Marcelo Silva (IG) marc...@ig.com.br escreveu: Pessoal, é possível fazer um select onde ele numera os registros trazidos? Exemplo: select sequencia, * from clientes Ou seja na primeira coluna gostaria de trazer 1,2,3,4... Só pra efeito de vizualizacao mesmo Você não falou a versão do PostgreSQL, mas a partir da 8.4 você pode usar row_number() [1]. [1] http://www.postgresql.org/docs/current/interactive/functions-window.html -- Dickson S. Guedes mail/xmpp: gue...@guedesoft.net - skype: guediz http://guedesoft.net - http://www.postgresql.org.br ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Modelagem (era: Função Update or Insert)
Em 14 de outubro de 2011 16:29, Shander Lyrio shan...@nucleo45.com.br escreveu: Em 14-10-2011 16:05, Alexsander Rosa escreveu: Em 14 de outubro de 2011 15:58, Shander Lyrio A tabela de CEP tem a grande utilidade de padronizar dados. Não se trata de armazenar um endereço como CEP mais alguma coisa, mas sim usar a tabela de CEPs para PREENCHER o endereço corretamente. Sem isso, uma rua com a palavra WASHINGTON acabaria sendo cadastrada com diversas grafias. O mesmo vale para os bairros: aqui em Porto Alegre tem um bairro chamado MONT SERRAT que, sem um cadastro de CEP (ou equivalente), seria preenchido de diversas maneiras criativas pelos usuários. Entendo bem isso e utilizo, mas sempre deixo aberto para o meu cliente poder mudar, até porque ruas mudam de nome e bairros também. Meu cep hoje 29092170 antes estava como sendo bairro Santa Terezinha, mas um outro bairro cresceu muito e os correios resolveram juntar todo mundo. Hoje este cep é do bairro Jardim Camburi. Não apenas isso: a maioria das cidades não tem CEP por logradouro. A discussão é sobre o cep ser uma chave natural e eu estou tentando mostrar ele não é porque o significado dele muda toda a hora. Com as UF também é assim, agora querem separar o Pará em vários estados. Mas isso não é motivo para ter um id_estado artificial ao invés da sigla como chave primária. Uma entidade com um único atributo faz com que ela se confunda com os valores atribuídos. Não lembro quem falou nisso. Eu falei apenas em usar como PK. Colocar M para Masculino e F para feminino é tão feio quanto 0 para Masculino e 1 para Feminino, porque em ambos os casos você criou um id para indicar o sexo, apenas mudou o tipo deste id. O fato de ser a primeira letra facilita a visualização do DBA, mas não aumenta ou reduz a complexidade das query's a não ser que você vá apresentar para o usuário final apenas a letra M ou F. M e F podem não apenas ser mostrados ao usuário: eles não requerem um JOIN para saber o sexo. -- Atenciosamente, Alexsander da Rosa http://rednaxel.com ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] pg_dump X pg_dumpall
Em 14 de outubro de 2011 16:27, Danilo Silva danilo.dsg.go...@gmail.com escreveu: Foi o que eu imaginei, visto o a diferença no tamanho entre eles, mas tem como gerar o dump por base com o comando create database? para em alguma emergência somente executar o script e não ter que criar o banco antes, e se for possível, como seria o sintaxe do comando pg_restore? No pg_dump a opção --create faria isso mas só faz sentido quando você usa pg_dump --format=text, isso está na documentação [1]. Já no caso de você utilizar pg_dump --format=custom para gerar o dump, é na hora do pg_restore que você especifica esta opção, também encontrada na documentação [2]. [1] http://www.postgresql.org/docs/current/static/app-pgdump.html [2] http://www.postgresql.org/docs/current/static/app-pgrestore.html -- Dickson S. Guedes mail/xmpp: gue...@guedesoft.net - skype: guediz http://guedesoft.net - http://www.postgresql.org.br ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Modelagem (era: Função Update or Insert)
Em 14-10-2011 16:44, Alexsander Rosa escreveu: A discussão é sobre o cep ser uma chave natural e eu estou tentando mostrar ele não é porque o significado dele muda toda a hora. Com as UF também é assim, agora querem separar o Pará em vários estados. Mas isso não é motivo para ter um id_estado artificial ao invés da sigla como chave primária. Aí é onde quero chegar, a sigla do estado nada mais é do que um id (intrínseco já que estamos acostumados). O mesmo para regiões, ao invés de usar um id 1, 2, 3, usamos um NE, SE que é mais representativo. Eu quando vejo um PR no endereço eu leio Paraná, os dois significam a mesma coisa para mim, não acho que sejam atributos diferentes, é apenas uma forma abreviada de falar o nome do estado. M e F podem não apenas ser mostrados ao usuário: eles não requerem um JOIN para saber o sexo. Os seus clientes, os meus clientes ou qualquer cliente? Não existe verdade absoluta, e eu já tive cliente, Banco inclusive, que queria M - Masculino no relatório. Obviamente isto não serve de nada, não agrega e ainda gasta tonner, mas o cliente pagou para ser feito deste jeito. Ah, já ia esquecendo, ele também pediu uma tela para cadastro de Sexos. Esse tipo de afirmação demonstra o maior defeito dos sistemas de hoje em dia. Eles são feito por programadores para programadores e não para usuários. Eu entendo da mesma forma que você disse, mas acredite quando digo nem todos os usuários finais de sistema entenderiam. Nunca subestime a ignorância de um usuário. Abraço, -- Shander Lyrio http://about.me/shander ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] pg_dump X pg_dumpall
Em 14-10-2011 15:57, Danilo Silva escreveu: Mas eu consigo listar o conteúdo do arquivo dumpall pelo pg_restore utilizando o parâmetro --list? Pois assim seria possível efetuar o restore de apenas um banco específico. Se estiver usando Linux, eu faço desta forma: http://pastebin.com/95KqQy8w Coloquei uma linha, mas resumindo, isto faz o backup automático de todos os bancos de dados do cluster para o diretório atual. Minha rotina é um pouco mais complexa pois separa os dump's semanal e mensal, mas a ideia básica é esta aí. Abraço, -- Shander Lyrio http://about.me/shander ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Modelagem (era: Função Update or Insert)
Em 14 de outubro de 2011 16:55, Shander Lyrio shan...@nucleo45.com.br escreveu: Aí é onde quero chegar, a sigla do estado nada mais é do que um id (intrínseco já que estamos acostumados). O mesmo para regiões, ao invés de usar um id 1, 2, 3, usamos um NE, SE que é mais representativo. Mas tem gente que acha que mesmo assim é preciso um id_estado integer (ou serial) como PK. M e F podem não apenas ser mostrados ao usuário: eles não requerem um JOIN para saber o sexo. Os seus clientes, os meus clientes ou qualquer cliente? Não existe verdade absoluta, e eu já tive cliente, Banco inclusive, que queria M - Masculino no relatório. Obviamente isto não serve de nada, não agrega e ainda gasta tonner, mas o cliente pagou para ser feito deste jeito. Ah, já ia esquecendo, ele também pediu uma tela para cadastro de Sexos. Estou falando que sou contra uma tabela assim: CREATE TABLE sexo (id_sexo integer primary key, desc_sexo text); Mas não sou contra uma tabela assim: CREATE TABLE sexo (id_sexo char(1) primary key, desc_sexo text); Aqui um CREATE DOMAIN ou um CHECK poderia ajudar. Veja que no segundo caso, acima, o seu cliente poderia ser atendido perfeitamente sem a criação de uma chave artificial numérica e sua respectiva SEQUENCE. Esse tipo de afirmação demonstra o maior defeito dos sistemas de hoje em dia. Eles são feito por programadores para programadores e não para usuários. Eu entendo da mesma forma que você disse, mas acredite quando digo nem todos os usuários finais de sistema entenderiam. Nunca subestime a ignorância de um usuário. A ignorância do usuário, por mais infinita que seja, deve afetar no máximo a UI -- nunca o modelo. Não aconselho ninguém a deixar que seus clientes interfiram na sua modelagem. -- Atenciosamente, Alexsander da Rosa http://rednaxel.com ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Modelagem (era: Função Update or Insert)
Date: Fri, 14 Oct 2011 16:15:34 -0300 From: shan...@nucleo45.com.br To: pgbr-geral@listas.postgresql.org.br Subject: Re: [pgbr-geral] Função Update or Insert Em 14-10-2011 15:53, Marcal Hokama escreveu: Uma tabela de cep's é apenas uma tabela cheia de dados em que o atributo cep é único e não se repete. Nada mais, um cep não pode ser usado como suficiente chave natural para identificar nada. O CEP como atributo de um endereço, tem um domínio, ou conjunto pré-definido de valores que é a relação de CEPs gerenciada pelos Correios, que tem uma estrutura definida em [1]. Se fosse modelar com base nessas informações, uma relação de CEPs poderia ser tanto um domínio como uma entidade (dúvida sobre ser realmente uma entidade - mas na prática iria virar uma tabela mesmo). Se os cep's não mudassem todo o ano eu até concordaria em dizer conjunto pré-definido, mas mudam. O que é um cep hoje, podem ser 2 amanhã, então nem adianta um on update cascade. Vejamos a situação, o atributo cep do endereço do cliente é uma foreign key para uma relação de ceps. No próximo ano os correios decidiram que este cep não existe mais, e agora? considerar cep como entidade te criaria um grande problema, porque derrepente, seu cliente passa a não ter mais cep ou a não ter um cep válido, ah, você tem uma restrição de integridade... então vá lá falar para os correios que eles não podem extinguir um cep. O que faremos?? Caso recente, a cidade em que eu nasci São Mateus-ES, tinha cep único 2993, já faz alguns anos que ele foi todo dividido porque a cidade cresceu, consulte o cep nos correios.. não existe mais. Mas até hoje, se você colocar o cep 2993 as encomendas chegam na casa dos meus pais certinho. No meu caso, a principal utilização do CEP, conforme foi comentado em outro post, é garantir o preenchimento do endereço de maneira correta a partir do preenchimento do CEP, como acontece em muitos sites/locais. Lembrei agora que, na verdade, o CEP é o meio para vincular por exemplo, um registro de um endereço a uma tabela geral de logradouros dos Correios. Aí é interesse pois cada logradouro tem um código único que não é o CEP. Quando o seu registro é vinculado diretamente ao logradouro, numa alteração de CEP no diretório dos correios, o logradouro passa a apontar para o novo CEP e assim o update cascadeou outro mecanismo semelhante de atualização é possível. Concordo sobre a parte que somente existência de uma única tabela de CEPs (no caso desta ser uma entidade) e a realidade de alterações promovidas pelos Correios poderiam inviabilizar a restrição de integridade, mas como escrevi anteriormente, o que é distribuído no Diretório Nacional de Endereços pelos Correios vai além dessa tabela, como a tabela de logradouros, permitindo efetuar melhores ações para manter a integridade e qualidade dos dados. Em [1] verifiquei uma relação das alterações promovidas pelos Correios no últimos anos. Mudanças acontecem, faz parte, da mesma maneira que muda a tabela de países, cidades, etc. Aí a questão seria manter a base de CEPs atualizada e endereçar as alterações. [1] http://www.correios.com.br/servicos/cep/alteracao_cep.cfm Atenciosamente, Marçal de Lima Hokama ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] NoSQL (era: Configurando Timezones por databases)
Date: Fri, 14 Oct 2011 17:16:09 -0300 From: fha...@gmail.com To: pgbr-geral@listas.postgresql.org.br Subject: Re: [pgbr-geral] NoSQL (era: Configurando Timezones por databases) Esta discussão ficou gostosa, entrando: (...) Você estava indo bem até citar PostGreSql. Não é uma questão de preferência sua. É um nome próprio, deve ser escrito como foi batizado, PostgreSQL ou Postgres. Ou você prefere ser chamado de MaRÇaL HoKaMa nos fórums? Flavio, olhe aí que não fui eu que escrevi PostGreSql. Se vai chamar atenção de alguém, chame da pessoa certa. Atenciosamente, Marçal de Lima Hokama ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] NoSQL (era: Configurando Timezones por databases)
Flavio, olhe aí que não fui eu que escrevi PostGreSql. Se vai chamar atenção de alguém, chame da pessoa certa. Não era pra chamar a atenção, era pra ser irônico :) A conversa tava ficando chata. Todavia, desculpe a falha, depois vi que sua resposta estava com double quote de outra pessoa. []s Flavio Gurgel ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] NoSQL (era: Configurando Timezones por databases)
Em 14/10/2011 17:16, Flavio Henrique Araque Gurgel escreveu: Outro dia um sistema que eu cuido, em PostgreSQL, fez 7 bilhões de SELECT num dia, com uns 30 milhões de INSERTs e UPDATEs, picos de 20.000 transações de banco de dados por segundo. Normal... apenas mais um dia de negócios. Partindo do princípio que eu acredito nisto, e que você tem situação parecida de 20 mil conexões diferentes cadastrando estes dados simultaneamente e não está fazendo um copy apenas... Você estava indo bem até citar PostGreSql. Não é uma questão de preferência sua. É um nome próprio, deve ser escrito como foi batizado, PostgreSQL ou Postgres. Ou você prefere ser chamado de MaRÇaL HoKaMa nos fórums? A caixa muda o nome? Então FLÁVIO é diferente de Flávio que é diferente de flávio? centenas de servidores e servindo 100k leituras e 20k escritas por segundo. O Skype faz isso com PostgreSQL. E olha que até a Microsoft se interessou por ele (e concretizou a compra hoje). E você acredita firmemente que este interesse da Microsoft foi pelo banco de dados que o Skype escolheu? 120k transações por segundo para 20k transações por segundo é uma diferença bem significativa. Mas o que tenho lido do Skype é que tem caído muito mais do que ficado de pé. Olhe as notícias recentes, abril para cá. O engraçado é que as respostas que tenho lido às minhas indagações dão a entender que eu sou contra o PostGreSql. Eu o utilizo e muito, ainda não tive motivos para trocá-lo por outro, mas dizer que ele é a resposta para tudo e que se o modelo relacional fosse sempre aplicado você teria todos os seus problemas resolvidos chega a soar infantil. -- Shander Lyrio http://aboute.me/shander ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Como posso obter um instalador msi do postgresql
Estou criando uma aplicação cliente do PostgreSQL. Quero insitalar o SGBD e iniciar o serviço antes de instalar meu software. Encontrei referências na documentação sobre a intalação silenciosa por meio do instalador .msi do Postgres e pareceu bastente simples mas, não encontro o instalador para download. Como posso obter uma cópia? Desde já agradeço pela ajuda. -- Ronaldo Adriano Kiiller Colégio Estadual Zulmira Marchesi da Silva - EFM Cornélio Procópio - PR (43)9125-1832 (43)3524-1944 ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Como posso obter um instalador msi do postgresql
Em 14 de outubro de 2011 19:37, Adriano admkiil...@gmail.com escreveu: Estou criando uma aplicação cliente do PostgreSQL. Quero insitalar o SGBD e iniciar o serviço antes de instalar meu software. Encontrei referências na documentação sobre a intalação silenciosa por meio do instalador .msi do Postgres e pareceu bastente simples mas, não encontro o instalador para download. Como posso obter uma cópia? Desde já agradeço pela ajuda. Qual sistema operacional? Windows? Linux? Você chegou a acessar a página de downloads [1] do PostgreSQL? [1] http://www.postgresql.org/download/ -- Dickson S. Guedes mail/xmpp: gue...@guedesoft.net - skype: guediz http://guedesoft.net - http://www.postgresql.org.br ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Como posso obter um instalador msi do postgresql
Estou usando o WindowsXP a aplicação foi feita em java, com o PostgreSQL 8.4. Já virei de ponta cabaça a página de downloads o postgre e não encontrei, também vistei a página de projetos do pgFondary o repositório cvs, também não encontrei nada. Se alguém tiver e puder me mandar por e-mail, ou se houver um jeito de instalar como um serviço e inicializa-lo a partir dos binários com usuário e senha padrão, sem que o usuário do meu aplicativo tenha que interagir com o instalador do Postgres? -- Ronaldo Adriano Kiiller Colégio Estadual Zulmira Marchesi da Silva - EFM Cornélio Procópio - PR (43)9125-1832 (43)3524-1944 ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Como posso obter um instalador msi do postgresql
Em 14 de outubro de 2011 20:26, Adriano admkiil...@gmail.com escreveu: Estou usando o WindowsXP a aplicação foi feita em java, com o PostgreSQL 8.4. Já virei de ponta cabaça a página de downloads o postgre e não encontrei, também vistei a página de projetos do pgFondary o repositório cvs, também não encontrei nada. Se alguém tiver e puder me mandar por e-mail, ou se houver um jeito de instalar como um serviço e inicializa-lo a partir dos binários com usuário e senha padrão, sem que o usuário do meu aplicativo tenha que interagir com o instalador do Postgres? Se você acessar o site [1] verá que tem um link Download the one click installer. Você também pode dar uma olhada neste PGCast [2], que mostra como instalar o PostgreSQL de 3 (treŝ) maneiras diferentes, apesar de ser para Linux, um dos métodos é justamente via one click installer e o passo a passo te mostra a página e como checar lá. [1] http://www.postgresql.org/download/windows [2] http://pgcasts.com/episodes/1-instalando-postgresql-9-0 -- Dickson S. Guedes mail/xmpp: gue...@guedesoft.net - skype: guediz http://guedesoft.net - http://www.postgresql.org.br ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Instalador msi
Obrigado Dickson. Parece que eu não havia procurado tão bem assim... Encontrei um link para download de um arquivo de instalação em formato zip, que continha o instalador msi. Obrigado novamente -- Ronaldo Adriano Kiiller Colégio Estadual Zulmira Marchesi da Silva - EFM Cornélio Procópio - PR (43)9125-1832 (43)3524-1944 ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] NoSQL (era: Configurando Timezones por databases)
Le 2011-O-14 17h56, Shander Lyrio a écrit : Partindo do princípio que eu acredito nisto, e que você tem situação parecida de 20 mil conexões diferentes cadastrando estes dados simultaneamente e não está fazendo um copy apenas... XaNnDDer, estás tão fixado em ganhares discussão perdidas, que vens com essa para cima d‘o cara’ do Multicanal da Caixa Econômica Federal? Por essas e outras decidi parar de te responder, mas como agora não é em causa própria… Se não tens conhecimento, respeita quem tem. A caixa muda o nome? Exato. Então FLÁVIO é diferente de Flávio que é diferente de flávio? Claro. E você acredita firmemente que este interesse da Microsoft foi pelo banco de dados que o Skype escolheu? Ninguém disse isso. 120k transações por segundo para 20k transações por segundo é uma diferença bem significativa. Mas o que tenho lido do Skype é que tem caído muito mais do que ficado de pé. Olhe as notícias recentes, abril para cá. Sim, mas com problemas de programação e autenticação, não de escala. O engraçado é que as respostas que tenho lido às minhas indagações dão a entender que eu sou contra o PostGreSql. Ninguém disse isso, mas tua vontade de ganhar de qualquer jeito já te fez dizer vários absurdos. Eu o utilizo e muito, ainda não tive motivos para trocá-lo por outro, mas dizer que ele é a resposta para tudo e que se o modelo relacional fosse sempre aplicado você teria todos os seus problemas resolvidos chega a soar infantil. Infantil é continuares a não saber a diferença entre SQL e relacional. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (11) 9406 7191ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT-3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] NoSQL (era: Configurando Timezones por databases)
Le 2011-O-14 15h39, Shander Lyrio a écrit : O MySql é muito usado hoje porque notadamente escala melhor em enormes quantidades de requisições. Ele consegue isto sendo apenas um repositório de dados com o myisan que é muito menos rigoroso com relação ao que o modelo relacional exige: restrição de tipos não é levada a sério, nada de foreign keys, transações, etc... Buahuahuahua! Mais do que provado que o MySQL só escala quando sofre cirurgia interna grave… ou seja, o MySQL do Google escala, o dos outros, não. E, aliás, o MyISAM escala inda menos que o InnoDB. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (11) 9406 7191ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT-3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] NoSQL (era: Configurando Timezones por databases)
Em 15-10-2011 00:01, Leandro Guimarães Faria Corce DUTRA escreveu: XaNnDDer, estás tão fixado em ganhares discussão perdidas, que vens com essa para cima d‘o cara’ do Multicanal da Caixa Econômica Federal? Por essas e outras decidi parar de te responder, mas como agora não é em causa própria… Se não tens conhecimento, respeita quem tem. Vejamos, antes de responder e dizer que eu não acredito, eu fiz uma pequena pesquisa no Google que me leva a uma entrevista dada pelo Sr. Flávio Gurgel onde ele diz que são picos de 6 milhões de transações dia e aponta este como sendo um dos maiores cases mundiais do PostGreSql. Ele vem agora neste e-mail falar de 7 bilhões/dia, ou seja muito mais que 1000x o valor da entrevista e você quer que eu acredite nisto? Se você acessar os links da entrevista vai ver que o volume comemorado é de 1000 transações por segundo e que foi inflacionado 20x na resposta do Sr. Flávio Gurgel. Você quer que eu respeite alguém, que por falta de argumentos, aumenta o número de transações sobremaneira para forçar um determinado entendimento? Eu não sei se alguém engoliu estes números sem pesquisar, ou se você mesmo engoliu sem pesquisar já que veio defendê-los, mas eu não engoli e continuo não engolindo até que me mostre um argumento convincente. O meu está aqui abaixo, os links com a entrevista do Sr. Flávio Gurgel. Estou aguardando os seus. http://www.4linux.com.br/PostgreSQL-Caixa-Economica-Federal-CEF http://www.4linux.com.br/Linux-Software-Livre-na-Caixa-Economica-Federal Ninguém disse isso, mas tua vontade de ganhar de qualquer jeito já te fez dizer vários absurdos. Não Leandro, não quero ganhar de ninguém. Quero aprender, tenho certeza que você tem muito mais experiência que eu e é bem possível que saiba muito mais do que eu sobre modelo relacional. Acontece que eu sou um aluno que pergunta e que não aceita as coisas goela abaixo, e você é um professor que não responde objetivamente, principalmente se as perguntas vierem acompanhadas de argumentos que ferem a sua teoria. Eu adoraria crer que o PostGreSql tem poder de fogo para suportar um ambiente tão hostil quanto o de um twitter ou facebook. Eu não preciso deste poder, que fique claro, mas saber que é possível já me deixaria muito feliz. O fato de você falar que tem condições sem argumentos não é suficiente. Infantil é continuares a não saber a diferença entre SQL e relacional. E você continua com esta história que eu não sei diferença de SQL e relacional para tentar desvalorizar os argumentos que foram postados e você não conseguiu responder (e deu a desculpa que não quer se tornar repetitivo). -- Shander Lyrio http://about.me/shander ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
