Excelente análise, bastante imparcial. Parabéns.
Em 22/01/08, junior Prado <[EMAIL PROTECTED]> escreveu: > > COMPARAÇÕES ENTRE MYSQL E POSTGRESQL > > > Cobertura do sql > > > Em termos de expressividade as linguagens suportadas pelos dois sistemas > > são bastante equivalentes. > > > Armazenamento e estrutura de dados > > > O MySQL no campo de armazenamento de dados prima principalmente pela > variedade. Fornece aos seus utilizadores a oportunidade de escolher a forma > de armazenamento que mais se adequa a utilização que irá dar à base de > dados. > > Ambos os sistemas usam as funcionalidades do Sistema Operacional para > organizar os dados em disco. > > O tipo de tabelas por omissão do MySQL guarda os dados sob a forma de > registos seqüenciais de tamanho fixo ou variável ao passo que o PostgreSQL > guarda todos os dados em Slotted Page(ponteiros apontados para registros). > > A primeira abordagem é mais genérica e pode ser usada em qualquer suporte > físico, a segunda tenta tirar o maior partido do suporte físico mais comum > para bases de dados: os discos magnéticos. > > 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) > > > Indexação > > > Embora ambos os sistemas permitam indexação, o MySQL é um pouco mais > limitado neste aspecto. > > A flexibilidade oferecida pela variedade de storage engines torna-se aqui > algo limitante quando alguns índices apenas estão disponíveis para alguns > tipos de tabelas. > > A funcionalidade de índices sobre parte da chave do MySQL pode ser > simulada em PostgreSQL com a funcionalidade de índices com uma função sobre > os atributos como chave (substring), ao mesmo tempo que permite funções mais > complexas. > > 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). > > O PostgreSQL não permite associar a organização de uma tabela com a ordem > de um índice, embora permita uma operação única de ordenação(CLUSTER). > > O MySQL não suporta nada como a indexação parcial do PostgreSQL, poupa > espaço ao impedir que os índices se tornem inúteis devido a estarem > populados com valores comuns e/ou desinteressantes. > > > Processamento e Otimização de queries > > > O otimizador e executor de queries do PostgreSQL são obviamente mais > avançados que os módulos correspondentes no MySQL. > > A simplicidade tanto do planejador como do executor de queries do MySQL > pode ser explicado pelo fato de este sistema apontar principalmente para o > uso em páginas web em que as queries nem são complicadas nem incidem numa > quantidade considerável de dados. > > Mais uma vez notamos numa dualidade de critérios sobre as funcionalidades > presentes dependendo do storage engine usado. > > 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. > > > Transações e controle de concorrência > > > Mais uma vez no MySQL as transações mostram serem uma funcionalidade > presente apenas para algumas escolhas no que diz respeito à forma de guardar > as tabelas. Será certamente uma pena não haver a possibilidade de se ter > acesso concorrente com algumas garantias de isolamento em tabelas onde se > pode querer usar índices fulltext, por exemplo. > > Esta abordagem mista também da luz a muitos casos especiais que o > programador deve ter cuidado se quiser (ou tiver de) misturar vários storage > engines. > > Por outro lado ao ter algoritmos menos complicados, ou simplesmente a não > os ter, de controle e gestão de concorrência, o MySQL pode ganhar na área da > eficiência. > > 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. > > O MySQL com as tabelas MyISAM é perfeitamente capaz de responder a uma > pergunta deste gênero consultando apenas meta-dados sobre a tabela, ou > índices. > > 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. > > > Suporte para base de dados distribuídas > > > 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. > > 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. > > > 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. > > Quando Usar o MySQL > > a. Back-end para geração de conteúdo de web sites; > > b. Aplicação envolvendo basicamente consultas e inserção de dados. Sugiro > não usar para aplicações com fortes demandas transacionais, (especialmente > se houverem atualizações concorrentes)! > > c. Empresas como o Yahoo Finance combinam o MySQL (aplicações web) com um > outro banco de dados (retaguarda financeira). > > Flickr também usa MySQL, e são mais de 800 queries simultâneas por > segundo, entre outras estatísticas surpreendentes. > > > O PostgreSQL: é para aplicações complexas, ou seja, quando envolvem um > grande volume de dados(acima de 5 milhões por dia) ou que tratam informações > críticas. > > 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. > > > -- > Valter Cezar Prado Junior > Analista TI > > Sem saber como fazer ele fez! > _______________________________________________ > pgbr-geral mailing list > [email protected] > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral > >
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
