Clique aqui para ler esse artigo em PDF.
Clique aqui para ler todos os artigos desta edição
Comparando Firebird, MySQL, PostgreSQL e SQLite
Muitas aplicações necessitam de um banco de dados que possa ser embutido ou que possibilite ser instalado no cliente e seja administrado pelo mesmo. Além disso, a crescente volatilidade nos negócios exige soluções flexíveis onde mudanças não impactem significativamente a infra-estrutura de TI. Há diversas soluções de armazenamento de dados disponíveis no mercado e as de código livre vêm ganhando destaque devido ao número cada vez maior de recursos oferecidos.
Neste artigo, será apresentada uma comparação entre quatro bancos de código livre de forma a apoiar o leitor na decisão por uma solução adequada às características do projeto. Três deles, Firebird, MySQL e PostgreSQL, bastante conhecidos no mercado e o quarto, SQLite, apesar de relativamente desconhecido, apresenta-se como uma opção muito interessante para tipos específicos de projetos. Para esta comparação, foram utilizadas as últimas versões disponíveis, no momento da escrita, dos bancos: Firebird 2.0, MySQL 5.0.26, PostgreSQL 8.2.0 e SQLite 3.3.8.
Antes, um pouco de história
Conhecer um pouco da história de cada banco ajuda a entender um pouco de seus principais objetivos e qualidades.
O Firebird é derivado (da versão 6) do InterBase, um banco de dados comercial da Borland que surgiu por volta de 1992 quando foi comprado pela empresa da Ashton-Tate (donos do dBase).
O desenvolvimento do MySQL foi iniciado em 1995 com a primeira versão em 1996. Foi concebido desde o início como um projeto de código livre onde a empresa por trás, a MySQL AB, obtém seus lucros a partir de serviços oferecidos. Sua principal característica era a performance, muito próxima aos principais bancos comerciais da época. Somente nos últimos anos tem agregado ao alto desempenho um conjunto de funcionalidades como triggers, procedimentos armazenados e “views”, que eram a grande carência dos usuários do MySQL.
O PostgreSQL nasceu de um projeto acadêmico há cerca de 20 anos como uma continuidade do Ingres (hoje da Computer Associates) e tinha o objetivo, como a maioria dos trabalhos acadêmicos, de explorar conceitos do estado da arte (estado da arte refere-se a novas tecnologias que surgem nos centros de pesquisa). Logo despertou interesse de outros desenvolvedores e em 1996 teve início como projeto de código livre. Recentemente, com o lançamento da versão 8, o PostgreSQL vem ganhando em performance, fator que era um de seus principais problemas.
O SQLite é o mais recente de todos — nasceu em 2000, já como código livre — e, diante de um mercado tão concorrido, oferece algo bem diferente: um banco de dados mínimo (tanto na instalação como na utilização e no consumo de recursos) que pode ser utilizado embutido em aplicações.
Como compará-los?
Para por os bancos lado a lado é necessário que sejam definidos os critérios de comparação objetivando avaliá-los sob a perspectiva apresentada no início do artigo. Nesse sentido, a idéia é eleger as características mais importantes que se deve observar considerando situações que ocorrem no dia-a-dia.
Este artigo surgiu a partir de um projeto real onde havia a restrição da escolha de ferramentas e tecnologias gratuitas, mas não necessariamente de código livre. O escopo do projeto envolve a construção de módulos diversos que apoiarão as atividades administrativas de uma instituição que coordena projetos, pesquisa e estudos tecnológicos. Trata-se de um tipo sistema de informação muito comum, basicamente de processamento de transações (solicitações, protocolos, envio de avisos etc.) e que será utilizado numa intranet via navegador web por cerca de 50 terminais. É importante ainda citar o volume de dados que deverá ser manipulado pelo SGBD: a expectativa é de que os dados úteis, desconsiderando o histórico em formato de “backup”, seja mantido em algo em torno de 5GB.
Nesse contexto, como o artigo foi originado de uma situação real de projeto, os critérios para a avaliação estão relacionados com o projeto, pois foram escolhidos segundo as suas necessidades. Entretanto, são relativamente gerais, já que essencialmente contemplam funcionalidades próprias dos SGBDs, e podem, portanto, ser facilmente adaptados para diversos contextos e projetos. No total, doze critérios foram definidos: suporte a “stored procedures”, “triggers”, cursores, XML, “domains”, transações e “views” atualizáveis, a velocidade de recuperação do banco em caso de falhas, se possui tipo de dados para moeda, os tipos de “lock” que podem ser utilizados, ferramentas disponíveis e a portabilidade dos bancos." [...] continue lendo...
