Artigo da SQL Magazine 41 - Comparando Firebird, MySQL, PostgreSQL e SQLite

Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Para efetuar o download você precisa estar logado. Clique aqui para efetuar o login
Confirmar voto
0
 (1)  (0)

Artigo da SQL Magazine - edição 41.

Capa SQl 33

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.

A seguir os critérios serão fundamentados e os recursos de cada banco expostos. Ao final do artigo serão feitas algumas considerações finais e será mostrado como os critérios foram utilizados na situação do projeto citada acima.

Stored procedures

Um procedimento armazenado é um procedimento semelhante ao de uma linguagem de programação que é armazenado no banco. Existem diversas razões para utilizá-los, dentre as mais importantes:

·         são componentes de software; não havendo necessidade de recriar toda a lógica para cada aplicação desenvolvida;

·         possuem maior performance já que evitam o tráfego na rede e utilizam “cache” assim como “prepared statments”;

·         são portáveis pois rodam em todas as plataformas nas quais o banco pode ser instalado.

 

Visto que o principal uso do SQLite é ser embutido em aplicações, fazendo com que algumas vantagens dos procedimentos armazenados percam sentido, o que se pode observar na Tabela 1 é que apenas este banco não suporta este recurso.

 

SGBD

Status

Comentários

Firebird

ü

 

MySQL

ü

Apenas para tabelas InnoDB.

PostgreSQL

ü

 

SQLite

 

 

Tabela 1. Stored procedures.

Triggers

Um gatilho é uma ação que o banco deve executar automaticamente sempre que certo tipo de operação for executado. Gatilhos são usados extensivamente em bancos de dados, pois evitam que instruções sejam codificadas dentro das aplicações sempre que certos eventos ocorrerem em uma tabela para manter a consistência dos dados.

Como dito anteriormente, gatilhos são usados extensivamente em banco de dados e a Tabela 2 mostra exatamente isto: todos os bancos suportam este recurso.

"

A exibição deste artigo foi interrompida :(
Este post está disponível para assinantes MVP

 
Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Receba nossas novidades
Ficou com alguma dúvida?