[pgbr-geral] Trigger
Preciso de uma função (trigger) para fazer buscar (pesquisas) dentro de varias tabelas de meu banco, se alguem souber de alguma coisa. Exemplo: Tenho um banco com aproximadamente umas 150 tables e preciso de uma função que eu passe os parametros como string e me retorno tudo o que ele encontrar nas 150 tables, ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Trigger
Em 25 de fevereiro de 2010 08:16, omar antonio omar.c...@gmail.comescreveu: Preciso de uma função (trigger) para fazer buscar (pesquisas) dentro de varias tabelas de meu banco, se alguem souber de alguma coisa. Exemplo: Tenho um banco com aproximadamente umas 150 tables e preciso de uma função que eu passe os parametros como string e me retorno tudo o que ele encontrar nas 150 tables, Para isso vc irá dar uma olhada em [1] para execução dinâmica de instruções SQL e em [2] para recuperar informações sobre os metadados no catálogo do PostgreSQL. [1] http://www.postgresql.org/docs/8.4/interactive/plpgsql-statements.html#PLPGSQL-STATEMENTS-EXECUTING-DYN [2] http://www.postgresql.org/docs/8.4/interactive/information-schema.html -- Fabrízio de Royes Mello Blog sobre TI: http://fabriziomello.blogspot.com ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Trigger
Bom dia, Em 25 de fevereiro de 2010 08:16, omar antonio omar.c...@gmail.comescreveu: Preciso de uma função (trigger) para fazer buscar (pesquisas) dentro de varias tabelas de meu banco, se alguem souber de alguma coisa. Exemplo: Tenho um banco com aproximadamente umas 150 tables e preciso de uma função que eu passe os parametros como string e me retorno tudo o que ele encontrar nas 150 tables, O que pedes não é uma trigger, mas sim uma função apenas (function). Triggers são gatilhos, ou seja, são controladores de eventos em um banco. Por exemplo, se, ao inserir dados em uma tabela precisas copiar os registros para uma tabela de log indicando o histórico, usarias uma trigger e esta chamaria uma função para executar a cópia dos registros. Para desenvolver o que desejas, imagino que tens duas opções: 1) criar uma função que explicitamente lê todas as tabelas seguidamente (bem tedioso de escrever, pelo número de tabelas) 2) criar uma função que leia os metadados do banco postgreSQL e com eles construa as instruções dinâmicas (SQL dinâmico). Tem sobre isso no link: http://www.postgresql.org/docs/8.4/interactive/plpgsql-statements.html#PLPGSQL-STATEMENTS-EXECUTING-DYN ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral Atenciosamente, -- André de Camargo Fernandes ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] OFF TOPIC - Crescimento faz Twitter trocar o MySQL
Em 24 de fevereiro de 2010 22:39, Professador de Idéias professa...@gmail.com escreveu: Desculpe minha ignorância, mas o que é escalar? É quando à medida que a carga de uso do banco aumenta (maior número de usuários e operações simultâneas, além de aumento da base de dados), o sistema minimiza a queda de performance ao máximo, sem a necessidade de uma grande manutenção. http://pt.wikipedia.org/wiki/Escalabilidade Vou te ensinar um recurso legal, que eu uso muito: no Google, quando quiser a definição de algo, digite define: termo que quer a definição. Resolve horrores. Só que nem sempre os resultados são bons... por exemplo: define: Padrão Te traz a seguinte definição humorística: Padre muito alto WTF!? :-P -- = Pablo Santiago Sánchez Análise e Desenvolvimento de Sistemas Web Zend Certified Engineer #ZEND006757 phack...@gmail.com (61) 9975-0883 http://www.sansis.com.br http://www.corephp.com.br Quidquid latine dictum sit, altum viditur = ___ 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 - Crescimento faz Twitter trocar o MySQL
Embora chame-se Escalabilidade e capacidade de escalar não é uma grandeza 100% mensurável no sentido de existir uma escala (como uma régua). São sempre resultados comparativos, ou seja, mudam de versão para versão, hardware para hardware, etc, etc, etc. O que geralmente se faz são benchmarks comparativos a fim de definir a melhor solução para um determinado caso. O que obtiver melhor tempo médio de resposta geralmente é o 100% na sua escala comparativa, e o restante é medido comparativamente. Cada banco tem sua vantagem e desvantagem em determinada área, por exemplo. Você escolhe no final qual o banco que mais atende as suas necessidades no quesito vantagens que ele apresente. http://pt.wikipedia.org/wiki/Benchmark_%28computa%C3%A7%C3%A3o%29 Em 24 de fevereiro de 2010 23:10, Professador de Idéias professa...@gmail.com escreveu: Conceito Interessante, tem ìndices para medir o grau de escalar ou oque indica que um bd precisar escalar? número de tuplas por tabela, usuários conectados ao mesmo tempo, tamanho em memória do dados? deve ser tudo isso junto... existe algum índice que junta tudo? Em 24 de fevereiro de 2010 22:44, Leandro DUTRA leandro.gfc.du...@gmail.com escreveu: 2010/2/24 Professador de Idéias professa...@gmail.com: Desculpe minha ignorância, mas o que é escalar? Agüentar muitos usuários, muitas transações, grande volume de dados… usar bem bastante memória, processadores… -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (11) 3854 7191 gTalk: xmpp:leand...@jabber.org +55 (11) 9406 7191 ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT-3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral -- = Pablo Santiago Sánchez Análise e Desenvolvimento de Sistemas Web Zend Certified Engineer #ZEND006757 phack...@gmail.com (61) 9975-0883 http://www.sansis.com.br http://www.corephp.com.br Quidquid latine dictum sit, altum viditur = ___ 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 - Crescimento faz Twitter trocar o MySQL
Mais um link que ajuda: http://pt.wikipedia.org/wiki/Transaction_Processing_Performance_Council 2010/2/25 Pablo Sánchez phack...@gmail.com: Embora chame-se Escalabilidade e capacidade de escalar não é uma grandeza 100% mensurável no sentido de existir uma escala (como uma régua). São sempre resultados comparativos, ou seja, mudam de versão para versão, hardware para hardware, etc, etc, etc. O que geralmente se faz são benchmarks comparativos a fim de definir a melhor solução para um determinado caso. O que obtiver melhor tempo médio de resposta geralmente é o 100% na sua escala comparativa, e o restante é medido comparativamente. Cada banco tem sua vantagem e desvantagem em determinada área, por exemplo. Você escolhe no final qual o banco que mais atende as suas necessidades no quesito vantagens que ele apresente. http://pt.wikipedia.org/wiki/Benchmark_%28computa%C3%A7%C3%A3o%29 Em 24 de fevereiro de 2010 23:10, Professador de Idéias professa...@gmail.com escreveu: Conceito Interessante, tem ìndices para medir o grau de escalar ou oque indica que um bd precisar escalar? número de tuplas por tabela, usuários conectados ao mesmo tempo, tamanho em memória do dados? deve ser tudo isso junto... existe algum índice que junta tudo? Em 24 de fevereiro de 2010 22:44, Leandro DUTRA leandro.gfc.du...@gmail.com escreveu: 2010/2/24 Professador de Idéias professa...@gmail.com: Desculpe minha ignorância, mas o que é escalar? Agüentar muitos usuários, muitas transações, grande volume de dados… usar bem bastante memória, processadores… -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (11) 3854 7191 gTalk: xmpp:leand...@jabber.org +55 (11) 9406 7191 ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT-3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral -- = Pablo Santiago Sánchez Análise e Desenvolvimento de Sistemas Web Zend Certified Engineer #ZEND006757 phack...@gmail.com (61) 9975-0883 http://www.sansis.com.br http://www.corephp.com.br Quidquid latine dictum sit, altum viditur = -- = Pablo Santiago Sánchez Análise e Desenvolvimento de Sistemas Web Zend Certified Engineer #ZEND006757 phack...@gmail.com (61) 9975-0883 http://www.sansis.com.br http://www.corephp.com.br Quidquid latine dictum sit, altum viditur = ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] [OFF] Fwd: Vaga Engenheiro de Redes
A quem interessar. Obs: não me mandem e-mail sobre a vaga, eu não tenho nada a ver com ela; não pergunte na lista, porque ficará sem nenhuma resposta (pelo menos da minha parte). -- Forwarded message -- From: Alexandre Vasconcelos alex.vasconce...@gmail.com Date: 2010/2/25 Subject: Vaga Engenheiro de Redes To: Pessoal, A Huawei Technologies Co., Ltd aqui em Brasília está contratando Engenheiro de Redes, se souberem de alguém por favor encaminhem o email e peçam para responder à mim. Segue abaixo o job description: Job Description: Responsibility: Carry out the network design including HLD and LLD based on the requirement from customer. Convert the requirement to Huawei Datacomm product configuration. Configure the routers/switches and perform troubleshooting. Attend the technical meeting with customer and carry out the acceptance test. Requirements: 1.CCIE/CCNP/CCNA and so on certifications; 2.Deep understanding for routing, switching, MPLS; 3.Strong experience on configuring/troubleshooting high-end Datacomm device. Familiar with VPN, QOS, TE, and protocols ISIS, OSPF, BGP. 4. Good responsibility, can work under strong pressures. 5.Fluent oral and written English. 6. Working experience is a plus. KEY WORDS: CCNP CCNA CCIE OSPF BGP MPLS A vaga é para Brasília/DF e um dos requisitos é disponibilidade para viajar pelo Brasil e, eventualmente, para fora. Valores de salários e benefícios serão discutidos durante o processo seletivo, de acordo com o perfil do candidato. Abs, Alexandre -- = Pablo Santiago Sánchez Análise e Desenvolvimento de Sistemas Web Zend Certified Engineer #ZEND006757 phack...@gmail.com (61) 9975-0883 http://www.sansis.com.br http://www.corephp.com.br Quidquid latine dictum sit, altum viditur = ___ 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] Fwd: Vaga Engenheiro de Redes
On Thu, Feb 25, 2010 at 10:04 AM, Pablo Sánchez phack...@gmail.com wrote: Pessoal, A Huawei Technologies Co., Ltd aqui em Brasília está contratando satira Ah! Sensacional!! Será que agora meu 3G E1725 vai estabilizar?? :-D /satira -Leo -- Leonardo Cezar http://www.aslid.org.br http://postgreslogia.wordpress.com ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] INSTALANDO A LINGUAGEM PERL
Galera, Ao executar o comando: create language plperlu; ERROR: could not access file $libdir/plperl: Arquivo ou diretório não encontrado Minha instalação foi binária e não passei os comandos --with-python --with-perl E agora, como recompilar a instalação ou setar o uso das bibliotecas em algum lugar? Att. -- VALTER CEZAR PRADO JUNIOR GRADUADO EM CIÊNCIA DA COMPUTAÇÃO - UFOP DBA / PROJETISTA DE SISTEMAS - PBH INTEGRANTE DA COMUNIDADE PGBR-GERAL TEL.: (31) 8402-2215 Sem saber como fazer ele fez! ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] INSTALANDO A LINGUAGEM PERL
2010/2/25 JUNIN CADÊ AS SOLUÇÕES . . . juninpr...@gmail.com: Galera, Ao executar o comando: create language plperlu; ERROR: could not access file $libdir/plperl: Arquivo ou diretório não encontrado Minha instalação foi binária e não passei os comandos --with-python --with-perl Como não sabemos distribuição, S.O., versão, ca, então vai a resposta: $ sudo apt-get install postgresql-8.4-plperl -Leo -- Leonardo Cezar http://www.aslid.org.br http://postgreslogia.wordpress.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] INSTALANDO A LINGUAGEM PERL
Bom dia 2010/2/25 JUNIN CADÊ AS SOLUÇÕES . . . juninpr...@gmail.com Galera, Ao executar o comando: create language plperlu; ERROR: could not access file $libdir/plperl: Arquivo ou diretório não encontrado você tem essa lib instalada ? já localizou ela ? Minha instalação foi binária e não passei os comandos --with-python --with-perl E agora, como recompilar a instalação ou setar o uso das bibliotecas em algum lugar? Não recompile, localize a lib em seu sistema, verifique o arquivo que aponta as libs, normalmente em /etc/ld.so.conf e como último recurso faça um link simbólico (ln -s) para o endereço onde a lib apontando para o endereço onde o PostgreSQL está procurando normalmente isso resolve. -- Marcelo Costa www.marcelocosta.net - “You can't always get what you want”, Doctor House in apology to Mike Jagger ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] INSTALANDO A LINGUAGEM PERL
Marcelo, Em primeiro lugar estou usando debian. Fui no arquivo /etc/ld.so.conf descobri que ele aponta para outro arquivo. Ele dá um include no /etc/ld.so.conf.d/ *conf então entrei nos arquivos .conf e obtive esses diretórios: /lib/i486-linux-gnu /usr/lib/i486-linux-gnu Entrei neles e criei o link simbolico abaixo ln -s /usr/lib/libperl.so.5.10 libperl.so.5.10 e continua dando a mesma resposta: ERROR: could not access file $libdir/plperl: Arquivo ou diretório não encontrado Entrei nos diretórios que criei o link simbolico e dei permissao total e nada... Em 25 de fevereiro de 2010 10:56, Marcelo Costa marcelojsco...@gmail.comescreveu: Bom dia 2010/2/25 JUNIN CADÊ AS SOLUÇÕES . . . juninpr...@gmail.com Galera, Ao executar o comando: create language plperlu; ERROR: could not access file $libdir/plperl: Arquivo ou diretório não encontrado você tem essa lib instalada ? já localizou ela ? Minha instalação foi binária e não passei os comandos --with-python --with-perl E agora, como recompilar a instalação ou setar o uso das bibliotecas em algum lugar? Não recompile, localize a lib em seu sistema, verifique o arquivo que aponta as libs, normalmente em /etc/ld.so.conf e como último recurso faça um link simbólico (ln -s) para o endereço onde a lib apontando para o endereço onde o PostgreSQL está procurando normalmente isso resolve. -- Marcelo Costa www.marcelocosta.net - “You can't always get what you want”, Doctor House in apology to Mike Jagger ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral -- VALTER CEZAR PRADO JUNIOR GRADUADO EM CIÊNCIA DA COMPUTAÇÃO - UFOP DBA / PROJETISTA DE SISTEMAS - PBH INTEGRANTE DA COMUNIDADE PGBR-GERAL TEL.: (31) 8402-2215 Sem saber como fazer ele fez! ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Problema com inicialização no lin ux
2010/2/25 Mauricio Merlin m...@uol.com.br:
Tenho postgres 8.1 instalado no debian, tive que reiniciar o servidor e
quando fui startar o pg me retorna o seguinte erro:
Insecure directory in $ENV{PATH} while running with -T switch at
/usr/share/postgresql-common/PgCommon.pm line 654.
Procurei na net, tentei resolver.. mas sem sucesso.
Qual foi o procedimento para iniciar o seu postgres?
O que te retorna o comando: pg_lsclusters
-Leo
--
Leonardo Cezar
http://www.aslid.org.br
http://postgreslogia.wordpress.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] INSTALANDO A LINGUAGEM PERL
JUNIN CADÊ AS SOLUÇÕES . . . escreveu: Ao executar o comando: create language plperlu; ERROR: could not access file $libdir/plperl: Arquivo ou diretório não encontrado Não sei o que você fez mas confira o que está abaixo. Veja que $libdir tem que ser a saída do comando pg_config e o nome da biblioteca compartilhada em tmpllibrary tem que corresponder ao arquivo no SO (sem a extensão). euler=# select tmplname,tmpllibrary from pg_pltemplate where tmplname ~ 'plperl'; tmplname | tmpllibrary --+ plperl | $libdir/plperl plperlu | $libdir/plperl (2 rows) euler=# \q $ /a/bin/pg_config --libdir /a/lib $ ls -la /a/lib/plperl* -rwxr-xr-x 1 euler euler 243291 Fev 18 19:57 /a/lib/plperl.so -- Euler Taveira de Oliveira http://www.timbira.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] INSTALANDO A LINGUAGEM PERL
Euler, Continuo com erro mas agora seu do meu problema. Fiz uma instalação binária e não passei o parâmetro --with-perl, assim sendo, não gerou o arquivo plperl.so Segundo este link - http://archives.postgresql.org/pgsql-novice/2003-05/msg00191.php , é necessário recompilar com o parâmetro --with-perl. Alguém poderia me passar o coamndo de como recompilar uma instalação binária de postgresql? PS.: Valeu Euler, seus comandos me indicaram o problema Att. Em 25 de fevereiro de 2010 12:27, Euler Taveira de Oliveira eu...@timbira.com escreveu: JUNIN CADÊ AS SOLUÇÕES . . . escreveu: Ao executar o comando: create language plperlu; ERROR: could not access file $libdir/plperl: Arquivo ou diretório não encontrado Não sei o que você fez mas confira o que está abaixo. Veja que $libdir tem que ser a saída do comando pg_config e o nome da biblioteca compartilhada em tmpllibrary tem que corresponder ao arquivo no SO (sem a extensão). euler=# select tmplname,tmpllibrary from pg_pltemplate where tmplname ~ 'plperl'; tmplname | tmpllibrary --+ plperl | $libdir/plperl plperlu | $libdir/plperl (2 rows) euler=# \q $ /a/bin/pg_config --libdir /a/lib $ ls -la /a/lib/plperl* -rwxr-xr-x 1 euler euler 243291 Fev 18 19:57 /a/lib/plperl.so -- Euler Taveira de Oliveira http://www.timbira.com/ ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral -- VALTER CEZAR PRADO JUNIOR GRADUADO EM CIÊNCIA DA COMPUTAÇÃO - UFOP DBA / PROJETISTA DE SISTEMAS - PBH INTEGRANTE DA COMUNIDADE PGBR-GERAL TEL.: (31) 8402-2215 Sem saber como fazer ele fez! ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] OFF TOPIC - Crescimento faz Twitter trocar o MySQL
Firebird escala também? Renato ___ 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 - Crescimento faz Twitter trocar o MySQL
Tudo escala, até um limite? George On Thu, Feb 25, 2010 at 1:54 PM, renato centrisco...@gmail.com wrote: Firebird escala também? Renato ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral -- George R. C. Silva Desenvolvimento em GIS http://blog.geoprocessamento.net (34) 9664-3717 (34) 8843-3717 ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Versão do Postgresql
Em 25 de fevereiro de 2010 16:21, Nilson Chagas nilson.chagas.si...@gmail.com escreveu: Pessoal, Contratei um novo host, e o banco de dados postgresql nele (segundo suporte que já veio sugerido) é o 8.1.18, no meu host antigo era o 8.2.7. Vocês me aconselham mudar a versão?? Se sim, para qual? Creio que o mais indicado é a versão mais atual. No momento: 8.4.2 Se não for possível mudar para a 8.4.x mude pelo menos para os releases mais recentes: 8.3.9, 8.2.15, 8.1.19 Osvaldo ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Versão do Postgresql
Então Osvaldo e Roberto, É um servidor dedicado, então vamos dizer ele é meu faço o que quiser. *risos* Ele esta com o CENTOS 5.4 x86_64 standard on server, tenho acesso via ssh, e administração via CPanel e WebHost Manager. Não sou DBA, conheço de banco de dados, mas não profundamente sobre configuração de banco de dados. Tenho receio de desistalar e perder a administração que vem com no painel. Será que alguém sabe se é possivel atualiar via WebHost Manager?? Ou uma maneira de fazer upload sem desinstação e instalação?? -- []s Nilson Chagas - Ubuntu User 25794 --- Visite: http://www.avozdoevangelho.com.br - Peça gratuitamente um curso Bíblico Twitter: avozdoevangelho Twitter: matrixspnet http://www.amados.com.br http://bbnradio.org - Ouça a rádio e faça gratuitamente um Curso Biblico On-Line 2010/2/25 Osvaldo Kussama osvaldo.kuss...@gmail.com Em 25 de fevereiro de 2010 16:21, Nilson Chagas nilson.chagas.si...@gmail.com escreveu: Pessoal, Contratei um novo host, e o banco de dados postgresql nele (segundo suporte que já veio sugerido) é o 8.1.18, no meu host antigo era o 8.2.7. Vocês me aconselham mudar a versão?? Se sim, para qual? Creio que o mais indicado é a versão mais atual. No momento: 8.4.2 Se não for possível mudar para a 8.4.x mude pelo menos para os releases mais recentes: 8.3.9, 8.2.15, 8.1.19 Osvaldo ___ 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
[pgbr-geral] Versão do Postgresql
Pessoal, Contratei um novo host, e o banco de dados postgresql nele (segundo suporte que já veio sugerido) é o 8.1.18, no meu host antigo era o 8.2.7. Vocês me aconselham mudar a versão?? Se sim, para qual? Grato -- []s Nilson Chagas - Ubuntu User 25794 --- Visite: http://www.avozdoevangelho.com.br - Peça gratuitamente um curso Bíblico Twitter: avozdoevangelho Twitter: matrixspnet http://www.amados.com.br http://bbnradio.org - Ouça a rádio e faça gratuitamente um Curso Biblico On-Line ___ 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 - Crescimento faz Twitter trocar o MySQL
Pessoal, Alguma referência bacana sobre esses NoSQL? Bene Daniel Gaspary escreveu: 2010/2/25 Leandro DUTRA leandro.gfc.du...@gmail.com: O problema é saber porque quer… as pessoas responsabilizam o SQL pelos defeitos de determinadas implementações e, pior ainda, responsabilizam o modelo relacional pelos problemas do SQL. Ah, sim, isso é verdade. Esses tempos conversava sobre isso na lista de python. Eu não tenho nada contra esses NoSQl, até acho alguns bem interessantes. Ainda não mexi, só li e vi alguns exemplos. Eu fico um pouco preocupado é com o nome. NoSQL. embora curtinho e sonoro, bom para promoção, parece, ainda que muito no fundo, um movimento contra. Além disso, curiosamente o nome indica um defeito que realmente existe nessas implementações. O nome só diz o que NÃO é. Porque são vários produtos, alguns com características bem diferentes, mas muitos completamente diferentes no modo de fazer as coisas. Como falei, acho bem interessante o uso desse tipo de solução. Mas vejo que muita gente busca nessas ferramentas a solução mágica onde vão jogar seus dados de qualquer maneira aos bilhões sem nunca avaliar nada e no fim eles estarão lá sempre super rápidos e disponíveis. Tem gente que acha chave estrangeira como preciosismo e depois reclama dos resultados. Quando esse tipo de desenvolvedor irresponsável começar a saltar para os NoSQL sem pensar em nada, esse tipo de solução também deve mostrar alguns defeitos pelo uso indiscriminado. Quando outra corrente avaliava, e concordo, que a responsabilidade é de quem planejou o sistema, não ficar culpando um ambiente ou linguagem. Ambientes, linguagens c são parte do planejamento, certo? Claro, quis dizer isso mesmo. Responsabilidade de quem planeja. Mesmo que tenham avaliado que realmente o problema era o Rails mesmo, fica parecendo uma atitude de gente irresponsável. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral -- Benedito A. Cruz Centro de Referência em Informação Ambiental - CRIA email b...@cria.org.br fone 55 19 3288 0466 -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ 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 - Crescimento faz Twitter trocar o MySQL
2010/2/25 George Silva georger.si...@gmail.com: Tudo escala, até um limite? Sim, mas… correr a 1km/h é correr? Explicando, escalar está para rodar como rodar para correr. Assim como um VLDB de vinte anos atrás não faz nem cócegas hoje. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (11) 3854 7191 gTalk: xmpp:leand...@jabber.org +55 (11) 9406 7191ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT-3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm Sent from Sao Paulo, SP, Brazil ___ 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 - Crescimento faz Twitter trocar o MySQL
Em 25 de fevereiro de 2010 16:17, Prof. Benedito A. Cruz b...@cria.org.br escreveu: Pessoal, Alguma referência bacana sobre esses NoSQL? Comece por: http://nosql-databases.org/ http://pt.wikipedia.org/wiki/NoSQL Osvaldo ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] OFF TOPIC - Crescimento faz Twitter trocar o MySQL
2010/2/25 Daniel Gaspary dgasp...@gmail.com: Olha, que o Postgres vai melhor em ambientes mais exigidos, é muito freqüente se ler. Em quaisquer ambientes, na verdade, dependendo de com o que se compara. Mas no caso específico, creio que a troca foi feita nem tanto por algum defeito do mysql. E sim porque como grande maioria dos desenvolvedores web, querem algo nesse estilo NoSQL . O problema é saber porque quer… as pessoas responsabilizam o SQL pelos defeitos de determinadas implementações e, pior ainda, responsabilizam o modelo relacional pelos problemas do SQL. Lembrando que o twitter mesmo é responsável por uma polêmica famosa : Rails Não escala. O que é fato. Mas o principal motivo, geralmente, é um mau modelo de dados que o Rails induz. Quando outra corrente avaliava, e concordo, que a responsabilidade é de quem planejou o sistema, não ficar culpando um ambiente ou linguagem. Ambientes, linguagens c são parte do planejamento, certo? -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (11) 3854 7191 gTalk: xmpp:leand...@jabber.org +55 (11) 9406 7191ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT-3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm Sent from Sao Paulo, SP, Brazil ___ 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 - Crescimento faz Twitter trocar o MySQL
2010/2/25 Leandro DUTRA leandro.gfc.du...@gmail.com: O problema é saber porque quer… as pessoas responsabilizam o SQL pelos defeitos de determinadas implementações e, pior ainda, responsabilizam o modelo relacional pelos problemas do SQL. Ah, sim, isso é verdade. Esses tempos conversava sobre isso na lista de python. Eu não tenho nada contra esses NoSQl, até acho alguns bem interessantes. Ainda não mexi, só li e vi alguns exemplos. Eu fico um pouco preocupado é com o nome. NoSQL. embora curtinho e sonoro, bom para promoção, parece, ainda que muito no fundo, um movimento contra. Além disso, curiosamente o nome indica um defeito que realmente existe nessas implementações. O nome só diz o que NÃO é. Porque são vários produtos, alguns com características bem diferentes, mas muitos completamente diferentes no modo de fazer as coisas. Como falei, acho bem interessante o uso desse tipo de solução. Mas vejo que muita gente busca nessas ferramentas a solução mágica onde vão jogar seus dados de qualquer maneira aos bilhões sem nunca avaliar nada e no fim eles estarão lá sempre super rápidos e disponíveis. Tem gente que acha chave estrangeira como preciosismo e depois reclama dos resultados. Quando esse tipo de desenvolvedor irresponsável começar a saltar para os NoSQL sem pensar em nada, esse tipo de solução também deve mostrar alguns defeitos pelo uso indiscriminado. Quando outra corrente avaliava, e concordo, que a responsabilidade é de quem planejou o sistema, não ficar culpando um ambiente ou linguagem. Ambientes, linguagens c são parte do planejamento, certo? Claro, quis dizer isso mesmo. Responsabilidade de quem planeja. Mesmo que tenham avaliado que realmente o problema era o Rails mesmo, fica parecendo uma atitude de gente irresponsável. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Versão do Postgresql
2010/2/25 Nilson Chagas nilson.chagas.si...@gmail.com: Pessoal, Contratei um novo host, e o banco de dados postgresql nele (segundo suporte que já veio sugerido) é o 8.1.18, no meu host antigo era o 8.2.7. Vocês me aconselham mudar a versão?? Se sim, para qual? MUITO antigo. Use no mínimo 8.3, e dê forte preferência ao 8.4. Não podes instalar seu próprio PostgreSQL? Roberto ___ 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 - Crescimento faz Twitter trocar o MySQL
Essas bases NoSQL, de certa forma não é um retrocesso? Não se parece com os records em pascal, gravados em disco? Renato ___ 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 - Crescimento faz Twitter trocar o MySQL
2010/2/25 renato centrisco...@gmail.com: Essas bases NoSQL, de certa forma não é um retrocesso? Não se parece com os records em pascal, gravados em disco? Bingo! Versão mais sofisticada do Prevayler, por um lado; por outro, herdeiros do MapReduce do Google, dos XML da vida… A questão é que o XML e o MapReduce foram criados por limitações do SQL e suas implementações, não por problemas do modelo relacional. Então a solução é melhorar o SQL e suas implementações e, talvez, criar uma outra linguagem, relacional… Pode ser que de fato NoSQL faça sentido em algumas situações. O movimento é que não faz sentido. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (11) 3854 7191 gTalk: xmpp:leand...@jabber.org +55 (11) 9406 7191ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT-3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm Sent from Sao Paulo, SP, Brazil ___ 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 - Crescimento faz Twitter trocar o MySQL
Leandro DUTRA escreveu: A questão é que o XML e o MapReduce foram criados por limitações do SQL e suas implementações, não por problemas do modelo relacional. Vale lembrar que mesmo essas limitações estão aos poucos aparecendo nos SGBDs (vide por exemplo hstore e FDW no PostgreSQL)... Pode ser que de fato NoSQL faça sentido em algumas situações. Situações que requerem escalabilidade horizontal pagando o preço de perder a garantia do ACID. No, thanks! Sem falar que com SQL/MED teremos a possibilidade de escalabilidade horizontal e mesmo o acesso a dados que não estão em bases relacionais de maneira transparente ao programador. -- Euler Taveira de Oliveira http://www.timbira.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] OFF TOPIC - Crescimento faz Twitter trocar o MySQL
Em 25 de fevereiro de 2010 18:16, Leandro DUTRA leandro.gfc.du...@gmail.com escreveu: 2010/2/25 renato centrisco...@gmail.com: Essas bases NoSQL, de certa forma não é um retrocesso? Não se parece com os records em pascal, gravados em disco? Bingo! Bingo nada! Só em uma análise muito superficial para achar isso. A idéia é justamente computação distribuída e replicação imediata, onde qualquer nó contém o dado, sem a necessidade de pesquisa nó a nó. Hoje, replicação em PostgreSQL limita-se a servidor de bkp, você não pode acessar qualquer server da replicação, só o master. No caso dos bancos NoSQL, especificamente o Cassandra, a idéia é justamente que não existe um master, nem slave, mas sim um cluster único. Versão mais sofisticada do Prevayler, por um lado; por outro, herdeiros do MapReduce do Google, dos XML da vida… A questão é que o XML e o MapReduce foram criados por limitações do SQL e suas implementações, não por problemas do modelo relacional. Então a solução é melhorar o SQL e suas implementações e, talvez, criar uma outra linguagem, relacional… Pode ser que de fato NoSQL faça sentido em algumas situações. O movimento é que não faz sentido. Claro que faz! Falando assim parece que você entendeu que é NoSQL de NãoSQL, quando na verdade é Not only SQL, ou seja, Não apenas SQL, não necessariamente excluindo o SQL como uma proposta. A verdade é que o modelo relacional não tem lá grandes problemas mesmo não, mas o SQL definitivamente sim, em especial trabalhando com Orientação a Objetos. Não deveria ser necessário eu fazer n consultas para carregar um Objeto e os Objetos correlatos, ou ainda ter que fazer inner joins que replicarão os dados n*n*n*...n de acordo com a quantidade de atributos que forem conjuntos de objetos pela multiplicação das matrizes para que então me retorne os dados tabularmente. O mais importante dos bancos NoSQL, é justamente o fato de eles permitirem o trabalho com dados multidimensionais. Há bancos que até permitem que certas colunas sejam arrays, mas não arrays de objetos, e sim arrays de valores escalares apenas. NoSQL preenche o gap que o SQL não consegue preencher para quem programa OO. -- = Pablo Santiago Sánchez Análise e Desenvolvimento de Sistemas Web Zend Certified Engineer #ZEND006757 phack...@gmail.com (61) 9975-0883 http://www.sansis.com.br http://www.corephp.com.br Quidquid latine dictum sit, altum viditur = ___ 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 - Crescimento faz Twitter trocar o MySQL
Em 25 de fevereiro de 2010 18:49, Euler Taveira de Oliveira eu...@timbira.com escreveu: Sem falar que com SQL/MED teremos a possibilidade de escalabilidade horizontal e mesmo o acesso a dados que não estão em bases relacionais de maneira transparente ao programador. Poderia me dizer quais bancos já suportam SQL/MED em nível de produção? (experimentos sobre um padrão que já tem 7 anos não contam muito). Fora que, basicamente, SQL/MED serve para acesso a dados externos via RDBMS, ou seja, ler Excel a partir do PostgreSQL... ou entendi muito errado? :-D (sim, falei Excel só para ser mau, suponho que com WebServices seja muito mais interessante). De qualquer forma, em que SQL/MED se compara a NoSQL? -- = Pablo Santiago Sánchez Análise e Desenvolvimento de Sistemas Web Zend Certified Engineer #ZEND006757 phack...@gmail.com (61) 9975-0883 http://www.sansis.com.br http://www.corephp.com.br Quidquid latine dictum sit, altum viditur = ___ 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 - Crescimento faz Twitter trocar o MySQL
2010/2/25 Euler Taveira de Oliveira eu...@timbira.com: Leandro DUTRA escreveu: A questão é que o XML e o MapReduce foram criados por limitações do SQL e suas implementações, não por problemas do modelo relacional. Vale lembrar que mesmo essas limitações estão aos poucos aparecendo nos SGBDs (vide por exemplo hstore e FDW no PostgreSQL)... Acho que não me fiz entender… quis dizer que uso de XML ou MapReduce para armazenar dados apareceu, ao menos em parte, por causa das limitações dos SGBDs, algumas derivadas do próprio SQL, outras de decisões de implementação. Ou eu fui quem não te entendeu, Euler? Sem falar que com SQL/MED teremos a possibilidade de escalabilidade horizontal e mesmo o acesso a dados que não estão em bases relacionais de maneira transparente ao programador. É, preciso voltar a estudar! -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (11) 3854 7191 gTalk: xmpp:leand...@jabber.org +55 (11) 9406 7191ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT-3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm Sent from Sao Paulo, SP, Brazil ___ 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 - Crescimento faz Twitter trocar o MySQL
2010/2/25 Pablo Sánchez phack...@gmail.com: Em 25 de fevereiro de 2010 18:04, renato centrisco...@gmail.com escreveu: Essas bases NoSQL, de certa forma não é um retrocesso? Não se parece com os records em pascal, gravados em disco? Não. A idéia é justamente computação distribuída. Parece, sim — não na localidade, mas na falta de garantia de integridade e de independência de (caminho de acesso a) dados. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (11) 3854 7191 gTalk: xmpp:leand...@jabber.org +55 (11) 9406 7191ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT-3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm Sent from Sao Paulo, SP, Brazil ___ 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 - Crescimento faz Twitter trocar o MySQL
Em 25 de fevereiro de 2010 18:04, renato centrisco...@gmail.com escreveu: Essas bases NoSQL, de certa forma não é um retrocesso? Não se parece com os records em pascal, gravados em disco? Não. A idéia é justamente computação distribuída. Além do que, eles tem a capacidade, normalmente, de retornar dados multidimensionais, o que para OO é perfeito. Ao invés de um retorno tabular (tuplas de colunas apenas), uma coluna pode conter outra tupla, que contém outra tupla, e por aí vai. Pelo que vi, parece que o Cassandra tem uma limitação de profundidade 5, mas não confirmei ainda essa informação 100% (vi em uma lib para usar o Cassandra, pode ser limitação apenas da lib). -- = Pablo Santiago Sánchez Análise e Desenvolvimento de Sistemas Web Zend Certified Engineer #ZEND006757 phack...@gmail.com (61) 9975-0883 http://www.sansis.com.br http://www.corephp.com.br Quidquid latine dictum sit, altum viditur = ___ 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 - Crescimento faz Twitter trocar o MySQL
Em 25 de fevereiro de 2010 19:18, Leandro DUTRA leandro.gfc.du...@gmail.com escreveu: 2010/2/25 Euler Taveira de Oliveira eu...@timbira.com: Leandro DUTRA escreveu: A questão é que o XML e o MapReduce foram criados por limitações do SQL e suas implementações, não por problemas do modelo relacional. Vale lembrar que mesmo essas limitações estão aos poucos aparecendo nos SGBDs (vide por exemplo hstore e FDW no PostgreSQL)... Acho que não me fiz entender… quis dizer que uso de XML ou MapReduce para armazenar dados apareceu, ao menos em parte, por causa das limitações dos SGBDs, algumas derivadas do próprio SQL, outras de decisões de implementação. Ou eu fui quem não te entendeu, Euler? Não, eu também não tinha te entendido. Sem falar que com SQL/MED teremos a possibilidade de escalabilidade horizontal e mesmo o acesso a dados que não estão em bases relacionais de maneira transparente ao programador. É, preciso voltar a estudar! Pelo que vi, na verdade, não muito, pois uma vez definida a fonte externa, basta consultá-la com SQL padrão mesmo. É uma questão de create foreign data wrapper apenas... http://www.postgresql.org/docs/8.4/static/sql-createforeigndatawrapper.html Vale destacar esta nota ao final: Note, however, that the SQL/MED functionality as a whole is not yet conforming. -- = Pablo Santiago Sánchez Análise e Desenvolvimento de Sistemas Web Zend Certified Engineer #ZEND006757 phack...@gmail.com (61) 9975-0883 http://www.sansis.com.br http://www.corephp.com.br Quidquid latine dictum sit, altum viditur = ___ 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 - Crescimento faz Twitter trocar o MySQL
Em 25 de fevereiro de 2010 19:21, Leandro DUTRA leandro.gfc.du...@gmail.com escreveu: 2010/2/25 Pablo Sánchez phack...@gmail.com: Em 25 de fevereiro de 2010 18:04, renato centrisco...@gmail.com escreveu: Essas bases NoSQL, de certa forma não é um retrocesso? Não se parece com os records em pascal, gravados em disco? Não. A idéia é justamente computação distribuída. Parece, sim — não na localidade, mas na falta de garantia de integridade e de independência de (caminho de acesso a) dados. http://queue.acm.org/detail.cfm?id=1466448 Não me pareceu, até o momento, falta de garantia de integridade dos dados. Até porque se pensarmos bem, tal garantia não existe realmente em nenhum dos modelos. Quantos bancos de dados já não foram para o espaço, mesmo sendo relacionais, mesmo garantido integridade relacional via triggers e tudo mais? A grande diferença do NoSQL é justamente o fato de dar margem a essa eventual consistência, no qual em determinado momento estará disponível a todos os bancos. A margem de erro é bem baixa na verdade. -- = Pablo Santiago Sánchez Análise e Desenvolvimento de Sistemas Web Zend Certified Engineer #ZEND006757 phack...@gmail.com (61) 9975-0883 http://www.sansis.com.br http://www.corephp.com.br Quidquid latine dictum sit, altum viditur = ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Versão do Postgresql
Cara, um amigo meu tem um serviço do gênero, onde ele tem root via ssh e o escambal. Mas o serviço que ele está, quando ele quer que algo seja atualizado, é só abrir um ticket de suporte especificando o que ele quer que o povo lá se vira para fazer funcionar. A princípio o CPanel não vai parar de funcionar, mas sempre há o risco... Veja a versão do CPanel disponível para você, e pesquise quais versões do PostgreSQL ele consegue administrar. Mas pelo que me lembre, o CPanel nada mais faz do que chamar o velho PHPPgAdmin de guerra na hora de administrar o banco... Em 25 de fevereiro de 2010 16:40, Nilson Chagas nilson.chagas.si...@gmail.com escreveu: Então Osvaldo e Roberto, É um servidor dedicado, então vamos dizer ele é meu faço o que quiser. *risos* Ele esta com o CENTOS 5.4 x86_64 standard on server, tenho acesso via ssh, e administração via CPanel e WebHost Manager. Não sou DBA, conheço de banco de dados, mas não profundamente sobre configuração de banco de dados. Tenho receio de desistalar e perder a administração que vem com no painel. Será que alguém sabe se é possivel atualiar via WebHost Manager?? Ou uma maneira de fazer upload sem desinstação e instalação?? -- []s Nilson Chagas - Ubuntu User 25794 --- Visite: http://www.avozdoevangelho.com.br - Peça gratuitamente um curso Bíblico Twitter: avozdoevangelho Twitter: matrixspnet http://www.amados.com.br http://bbnradio.org - Ouça a rádio e faça gratuitamente um Curso Biblico On-Line 2010/2/25 Osvaldo Kussama osvaldo.kuss...@gmail.com Em 25 de fevereiro de 2010 16:21, Nilson Chagas nilson.chagas.si...@gmail.com escreveu: Pessoal, Contratei um novo host, e o banco de dados postgresql nele (segundo suporte que já veio sugerido) é o 8.1.18, no meu host antigo era o 8.2.7. Vocês me aconselham mudar a versão?? Se sim, para qual? Creio que o mais indicado é a versão mais atual. No momento: 8.4.2 Se não for possível mudar para a 8.4.x mude pelo menos para os releases mais recentes: 8.3.9, 8.2.15, 8.1.19 Osvaldo ___ 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 -- = Pablo Santiago Sánchez Análise e Desenvolvimento de Sistemas Web Zend Certified Engineer #ZEND006757 phack...@gmail.com (61) 9975-0883 http://www.sansis.com.br http://www.corephp.com.br Quidquid latine dictum sit, altum viditur = ___ 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 - Crescimento faz Twitter trocar o MySQL
Pablo Sánchez escreveu: Em 25 de fevereiro de 2010 18:49, Euler Taveira de Oliveira eu...@timbira.com escreveu: Sem falar que com SQL/MED teremos a possibilidade de escalabilidade horizontal e mesmo o acesso a dados que não estão em bases relacionais de maneira transparente ao programador. Poderia me dizer quais bancos já suportam SQL/MED em nível de produção? (experimentos sobre um padrão que já tem 7 anos não contam muito). DB2. Mas tem outros SGBDs que já tem algumas coisas como o PostgreSQL. Fora que, basicamente, SQL/MED serve para acesso a dados externos via RDBMS, ou seja, ler Excel a partir do PostgreSQL... ou entendi muito errado? :-D (sim, falei Excel só para ser mau, suponho que com WebServices seja muito mais interessante). De qualquer forma, em que SQL/MED se compara a NoSQL? Você leu o que eu disse acima: escalabilidade horizontal. E por fonte de dados externa podemos incluir o *PostgreSQL* e qualquer outra fonte de dados (XML, JSON, CSV, MySQL, DB2, etc) . SQL/MED é um modelo ambicioso. Distribuir a carga de uma consulta para múltiplos nós em que até mesmo esses nós possam ter modelos de dados diferentes. Há muita pesquisa em cima dessas idéias na área de banco de dados hoje. Além disso, o que poucos enxergam é que no caso dos nós serem PostgreSQL podemos ter heurísticas no planejador para decidir para onde direcionar as consultas. -- Euler Taveira de Oliveira http://www.timbira.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] OFF TOPIC - Crescimento faz Twitter trocar o MySQL
Aproveito para deixar este post sobre o assunto: http://openquery.com/blog/sql-nosql Marçal --- Date: Thu, 25 Feb 2010 16:23:19 -0300 From: osvaldo.kuss...@gmail.com To: pgbr-geral@listas.postgresql.org.br Subject: Re: [pgbr-geral] OFF TOPIC - Crescimento faz Twitter trocar o MySQL Em 25 de fevereiro de 2010 16:17, Prof. Benedito A. Cruz b...@cria.org.br escreveu: Pessoal, Alguma referência bacana sobre esses NoSQL? Comece por: http://nosql-databases.org/ http://pt.wikipedia.org/wiki/NoSQL Osvaldo ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral _ Quer deixar seus vídeos mais divertidos? Com o Movie Maker isso fica fácil. http://www.windowslive.com.br/public/tip.aspx/view/87?product=4ocid=Windows Live:Dicas - Movie Maker:Hotmail:Tagline:1x1:Titulo Legendas Creditos___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Versão do Postgresql
2010/2/25 Pablo Sánchez phack...@gmail.com Cara, um amigo meu tem um serviço do gênero, onde ele tem root via ssh e o escambal. Mas o serviço que ele está, quando ele quer que algo seja atualizado, é só abrir um ticket de suporte especificando o que ele quer que o povo lá se vira para fazer funcionar. A princípio o CPanel não vai parar de funcionar, mas sempre há o risco... Veja a versão do CPanel disponível para você, e pesquise quais versões do PostgreSQL ele consegue administrar. Mas pelo que me lembre, o CPanel nada mais faz do que chamar o velho PHPPgAdmin de guerra na hora de administrar o banco... Então eu passei a bola para o suporte veja a resposta que tive: Pelo que verificamos a versão mais recente disponível pelos desenvolvedores da distribuição CentOS é a 8.1.18, por isso essa foi a versão instalada pelo script de instalação do Cpanel. É sempre feita a instalação da versão mais recente disponibilizada pela distribuição Linux usada. Recomendamos que você utilize a versão já instalada até que a nova versão seja distribuida pela CentOS. A não ser que esteja muito enganado, mas acredito que isto não procede. Se a distribuição não oferece em seus pacotes, tem que ser feito na unha, ou estou errado?? -- []s Nilson Chagas - Ubuntu User 25794 --- Visite: http://www.avozdoevangelho.com.br - Peça gratuitamente um curso Bíblico Twitter: avozdoevangelho Twitter: matrixspnet http://www.amados.com.br http://bbnradio.org - Ouça a rádio e faça gratuitamente um Curso Biblico On-Line ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Versão do Postgresql
Em 25 de fevereiro de 2010 22:21, Nilson Chagas nilson.chagas.si...@gmail.com escreveu: Então eu passei a bola para o suporte veja a resposta que tive: Pelo que verificamos a versão mais recente disponível pelos desenvolvedores da distribuição CentOS é a 8.1.18, por isso essa foi a versão instalada pelo script de instalação do Cpanel. É sempre feita a instalação da versão mais recente disponibilizada pela distribuição Linux usada. Recomendamos que você utilize a versão já instalada até que a nova versão seja distribuida pela CentOS. A não ser que esteja muito enganado, mas acredito que isto não procede. Se a distribuição não oferece em seus pacotes, tem que ser feito na unha, ou estou errado?? Sim, mas nesse caso o suporte não o fará para você. Eles se limitam a dar suporte àquilo que eles podem automatizar, afinal de contas, você não é o unico cliente deles. Se por algum motivo, sua versão compilada na unha parar de funcionar, eles definitivamente não vão ter a menor idéia de como corrigir, e provavelmente não vão nem conseguir verificar o configure --version para saber como tinha sido compilado antes e repetir a operação. Ou seja, nesse caso, se você o fizer, terá que fazer na mão, sozinho e assumir o risco de estragar tudo. Se não tem nada ainda rodando no servidor, pode até valer a pena se arriscar 1 ou 2 vezes. Se baixar o PostgreSQL e compilar do fonte sem alterar o prefiz, ele colocar tudo automaticamente no /usr/local/pgsql, ou seja, fica fácil para remover, é só apagar essa pasta e começar de novo do zero. E se nada mais der certo, você pode pedir a eles que reinstalem o servidor tal qual estava quado foi contratado, porque com certeza eles tem alguma imagem pronta para colocar em um jail. Quando o PG estava na versão 7, escrevi este artigo. Está desatualizado, mas praticamente tudo que está aí ainda é válido. O que não for válido, é fácil de ver no manual como mudou. http://www.idsl.org.br/index.php?cont_cod=48 Um abc Obs; se você o fizer, não venha me responsabilizar caso estrague tudo. Como disse, a documentação está desatualizada, e eu tenho utilizado o ports do FreeBSD para instalar o PG. -- = Pablo Santiago Sánchez Análise e Desenvolvimento de Sistemas Web Zend Certified Engineer #ZEND006757 phack...@gmail.com (61) 9975-0883 http://www.sansis.com.br http://www.corephp.com.br Quidquid latine dictum sit, altum viditur = ___ 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 - Crescimento faz Twitter trocar o MySQL
Em 25 de fevereiro de 2010 20:42, Euler Taveira de Oliveira eu...@timbira.com escreveu: Pablo Sánchez escreveu: Poderia me dizer quais bancos já suportam SQL/MED em nível de produção? (experimentos sobre um padrão que já tem 7 anos não contam muito). DB2. Mas tem outros SGBDs que já tem algumas coisas como o PostgreSQL. O do PostgreSQL ainda está com muitas arestas (mandei o texto do próprio manual mais cedo). Legal o DB2, eu ainda não tive a oportunidade de utilizá-lo, e meu tempo de estudo por diversão anda meio devagar... De qualquer forma, em que SQL/MED se compara a NoSQL? Você leu o que eu disse acima: escalabilidade horizontal. Sim, li, mas o conceito que encontrei não me pareceu similar a escalabilidade, está mais para para uma distribuição horizontal dos dados, que continuam centralizados em um ponto apenas, não é um sistema distribuído, mas um monte de fontes distribuídas. As requisições ainda tem que passar por um único master. Você pode até colocar vários master para cada fonte de dados distinta, mas ainda assim, na hora de cruzar as informações, passa por um master. A proposta de banco NoSQL é justamente trabalhar com cloud computing, e a proposta dos SGDBs disponíveis ainda é trabalhar com um único master e vários slaves para replicação. E por fonte de dados externa podemos incluir o *PostgreSQL* e qualquer outra fonte de dados (XML, JSON, CSV, MySQL, DB2, etc) . SQL/MED é um modelo ambicioso. Sim, é, mas acho que está ocorrendo uma confusão nos conceitos. Distribuir a carga de uma consulta para múltiplos nós em que até mesmo esses nós possam ter modelos de dados diferentes. Sim, mas mesmo assim, ainda passam por um master... Para você mesclar as fontes de dados em uma consulta, eles ainda passarão por um único master. O master trás os dados de múltiplas fontes, mas isso não é distribuição de carga por nós. Não é o mesmo conceito. Na verdade, nesse aspecto me parece até pior, porque além de eu ter que solicitar ao master, ele vai solicitar a várias fontes ao mesmo tempo, criar um bottleneck nas interfaces de rede do servidor, pois para que ele possa cruzar as informações ele terá que ter acesso a elas, e gerar a carga ainda na fonte de dados. Um SGDB que precisa consultar outros 3 SGDBs para obter a informação não é um uso inteligente dos recursos disponíveis. Claro, resolve uma série de problemas, como a integração entre fontes de dados distintas, mas o processamento é realizado por todos os nós envolvidos, e só o master está respondendo no final. A idéia com o Cassandra, especificamente, é outra, é justamente não fazer isso. Não há, diretamente, no modelo proposto pelo SQL/MED, um balanceamento de carga, e os dados não estão disponíveis em todos os nós ao mesmo tempo. Essa é a grande diferença do Cassandra. Mesclar fontes de dados é completamente diferente de ter uma mesma fonte de dados distribuída por vários computadores. Há muita pesquisa em cima dessas idéias na área de banco de dados hoje. Não duvido nada disso. Aliás, pelo que pude ver, realmente é uma excelente idéia, resolverá várias questões, até eliminará a necessidade de extensões como o DBLink, mas não passa disso: uma implementação similar ao DBLink. Continuamos com apenas um master, e a carga de processamento não é distribuído, mas multiplicada entre as diversas fontes acessadas pelo master. Além disso, o que poucos enxergam é que no caso dos nós serem PostgreSQL podemos ter heurísticas no planejador para decidir para onde direcionar as consultas. Novamente: SQL/MED não é distribuição dos mesmos dados por diversos nós, mas acesso de diversos dados por um único nó. O restante, não passa de replicação. -- = Pablo Santiago Sánchez Análise e Desenvolvimento de Sistemas Web Zend Certified Engineer #ZEND006757 phack...@gmail.com (61) 9975-0883 http://www.sansis.com.br http://www.corephp.com.br Quidquid latine dictum sit, altum viditur = ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Lancamento replicationz2
Lançamento da versão beta replicationZ2 criado para simplificar a tarefa de replicar dados, feito em java. Teve um video publicado do seu funcionamento em http://www.postgresql.org.br/ agora disponivel para download em http://code.google.com/p/replicationz2/ Video 1 º exemplo em http://www.youtube.com/watch?v=gu0Lbf3M58wfeature=channel Ajudem a desenvolver a ferramenta, sugestões são bem vindas. Obrigado Att. sandro.ci02 ___ 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 - Crescimento faz Twitter trocar o MySQL
Pablo Sánchez escreveu: Em 25 de fevereiro de 2010 20:42, Euler Taveira de Oliveira eu...@timbira.com escreveu: [corte] O do PostgreSQL ainda está com muitas arestas (mandei o texto do próprio manual mais cedo). É verdade. Está na minha lista de afazeres mas a prioridade anda meio baixa. Talvez se surgir algum cliente interessado... Não duvido nada disso. Aliás, pelo que pude ver, realmente é uma excelente idéia, resolverá várias questões, até eliminará a necessidade de extensões como o DBLink, mas não passa disso: uma implementação similar ao DBLink. Continuamos com apenas um master, e a carga de processamento não é distribuído, mas multiplicada entre as diversas fontes acessadas pelo master. É claro que o processamento pode ser distribuído. Considere um SGBD com duas tabelas estrangeiras (aka foreign tables) de um outro nó. Uma junção dessas duas tabelas irá transferir o processamento para o outro nó. O papel do mestre será somente acessar o outro nó e depois repassar os dados retornados. Além disso, o que poucos enxergam é que no caso dos nós serem PostgreSQL podemos ter heurísticas no planejador para decidir para onde direcionar as consultas. É não são todos que enxergam... Novamente: SQL/MED não é distribuição dos mesmos dados por diversos nós, mas acesso de diversos dados por um único nó. O restante, não passa de replicação. É fato que o SQL/MED proporciona: agregação de dados de fontes distintas (ou como você prefere dizer, distribuição dos dados em diversas fontes), mas o que eu estou querendo dizer é que isso de uma certa forma trás consigo uma certa escalabilidade horizontal. Eu não quero entrar na discussão de BDs distribuídos aqui mas... Esse conceito de consistência eventual (como o utilizado nessas soluções NoSQL) já é antigo e, de certa forma, prega o oposto das propriedades ACID. É claro que a solução tem o seu mérito (você precisa escalar sem dar muito valor aos dados armazenados) mas isso já está disponível a um bom tempo em SGBDs relacionais (vide replicação multi-mestre assíncrona). Por fim, o grande diferencial dessas soluções NoSQL é com relação ao *modelo* (não utilizam o modelo relacional). -- Euler Taveira de Oliveira http://www.timbira.com/ ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
