junior Prado wrote: > A possibilidade de compressão de alguns dados oferecida pelo MySQL pode > ser uma mais-valia para ambientes onde os recursos são escassos.(ex. > sistemas embutidos) > O PostgreSQL também suporta isso. Vide ALTER TABLE foo ALTER bar SET STORAGE [1]. Isso se você quiser forçar o armazenamento de uma coluna "fora" da tabela em si; ele já faz isso automaticamente se os dados forem maiores do que x bytes.
> Embora o MySQL possua um indexador de fulltext bastante flexível, o > PostgreSQL tem dois mecanismos de indexação sobre os quais podem ser > construídos quaisquer índices (em teoria) e onde foram de fato > construídos índices de fulltext, presente nos módulos contribuídos > (tsearch2). > Não entendi o "em teoria". Podes explicar? Lendo o artigo sobre o GiST vi que ele permite "encaixar" quaisquer tipos de índices na infra-estrutura dele. > O MySQL permite, no entanto, uma forma mais fácil de dar indicações > sobre como realizar as operações, funcionalidade que no PostgreSQL é > bastante mais difícil, para algumas dicas até mesmo impossível de conseguir. > Ugh? Tenho que discordar neste ponto. O que você quer dizer com mais "fácil". Utilizar sintaxes que não estão no padrão é ser "fácil"? Os usuários MySQL sentem dificuldade com o PostgreSQL e qualquer outro SGBD que implementa boa parte do padrão justamente porque a sintaxe do MySQL é *diferente*. O argumento de que "no MySQL é assim", *não* ajuda na hora de convencer os desenvolvedores do PostgreSQL a utilizarem uma sintaxe diferente do padrão. > Um exemplo disto é a execuções da função de agregação count. Enquanto > que devido ao fato de se ter de ler as tuplas da página de forma a > determinar a sua visibilidade para a transações corrente, no PostgreSQL > a melhor forma de responder a uma pergunta com essa funções é > percorrendo toda a relações, o que em alguns casos pode ser muito demorado. > Concordo. É uma das deficiências do MVCC. Mas há maneiras de se contornar isso: (i) materializando o COUNT() em uma outra tabela (ii) utilizando o resultado de estatísticas. > O sistema de controle de transações do PostgreSQL parece ser bastante > mais robusto e consistente. O fato de sua semântica e gestão das tuplas > requerer manutenção temporária pode ser visto como outra desvantagem das > escolhas tomadas. > A cada dia esta manutenção está diminuindo. ;) Coisas como FILLFACTOR, HOT e autovacuum diminuem bruscamente a necessidade de manutenções (aka VACUUM). > Embora também seja possível obter replicações de bases de dados > PostgreSQL usando os seus logs, não é uma funcionalidade de fácil acesso > pelo que para todos os efeitos consideramos que o PostgreSQL poderia > oferecer um pouco mais neste aspecto. > Ugh? Novamente o que seria "facilidade"? Prefiro a palavra flexibilidade. Você precisa ajustar dois parâmetros no postgresql.conf e fazer um backup físico dos dados. Não venha me falar que no MySQL não é mais ou menos assim também? > O MySQL fornece uma forma bastante transparente (um storage engine) de > acessar remotamente a outras bases de dados, funcionalidade que está em > falta no PostgreSQL. Mesmo não sendo suporte consagrado para > distribuição da base de dados uma vez que não mantém o esquema da tabela > sincronizado, nem permite a criação transparente de tabelas em hosts > remotos, uma funcionalidade com bastante utilidade. > Não entendi o que você quis dizer como acesso remoto a outras bases de dados. Tenho a leve impressão de que isso é o que o dblink ou dbi-link fazem. > Conclusões > > > O MySQL: É o mais ágil, pois é otimizado para proporcionar processamento > rápido dos dados e tempo curto de resposta sem exigir muito do hardware. > Acho que você não pode concluir isso. Já viu alguns benchmarks da Tweakers.net [2]? > Quando Usar o MySQL > > a. Back-end para geração de conteúdo de web sites; > Por que não o PostgreSQL? > Flickr também usa MySQL, e são mais de 800 queries simultâneas por > segundo, entre outras estatísticas surpreendentes. > Isso é tranquilo para o PostgreSQL. > Quando Usar o PostgreSQL > > Aplicações com fortes componentes transacionais. Aplicações que > necessitem de tipos de dados especializados, como Sistemas de > Informações Geográficas (SIG) e repositórios de meta-dados. Projetos > baseados em metodologias Orientadas Objeto - perda de compatibilidade > com o padrão ANSI SQL Aplicações OLAP "light", que não necessitem do > nível de sofisticação de um DataWarehouse. > Não entendi esta última frase. "perda de compatibilidade" com padrão? Não seria: aplicações que querem ser compatíveis com o padrão? Realmente o PostgreSQL é deficiente na parte de comandos OLAP. [1] http://www.postgresql.org/docs/8.3/static/sql-altertable.html [2] http://tweakers.net/reviews/657/6 -- 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
