Como garantir a integridade dos dados em nossa base e ao mesmo tempo deixar o banco rápido, sem precisar colocar no sistema inúmeras verificações para validar os dados? Fácil, podemos utilizar alguns dos recursos que o banco de dados nos oferece como os que vou mostrar durante este artigo.

Neste artigo, vou falar um pouco sobre rule, trigger e function e o quanto eles podem ajudar no sentido de manter um bom desempenho e a integridade dos dados, inclusive deixando o código fonte do sistema menor e de fácil manutenção.

Para o exemplo

Para este artigo vamos imaginar a seguinte situação: uma empresa que trabalha com entrega de correspondência e produtos, uma espécie de “door to door”. Essa empresa usa um sistema de leitura para manter o controle da correspondência até seu destino final.

Exemplo: Um produto sai da filial de São Paulo, com destino ao Espírito Santo, só que antes de ir para ES, ele passa pelo Rio de Janeiro. Ou seja, o produto antes de chegar ao seu destino final vai ser registrado três vezes como mostram a figura 1.

Figura 1. Diagrama do processo de leitura de correspondência.

Imagine também que em cada passagem do produto, é tirado um relatório de romaneio, que é entregue ao motorista que leva o produto para seu destino final. Esse relatório de romaneio é tirado a partir de um número de lote que o próprio sistema gera.

A partir dessas informações, será criado uma espécie de “rastreamento” desse produto. Para fazer isto, imagine duas tabelas, uma tabela principal, onde vai ser registrada a primeira passagem do produto, e uma tabela de passagens, onde entrarão as demais passagens até o seu destino final.

Agora vem a questão: Como fazer para saber quando é a primeira passagem do produto e quando são as demais?

Para esta pergunta existem duas sugestões:

1. Colocar comandos SQL dentro do sistema, checando se o produto existe ou não na tabela principal. Se existir, gravar na tabela de passagem, se não existir, gravar na tabela principal e depois na de passagem (Optei por gravar a primeira passagem na tabela de passagens também, pois ai deixa minha tabela principal somente para gerar os relatórios de romaneios).

2. Criar regras no banco de dados para verificar se o produto existe ou não, e na própria regra fazer com que os dados sejam distribuídos nas tabelas.

Entre as duas sugestões, pela lógica, vamos optar pela segunda, pois assim vai haver um desempenho maior tanto no banco de dados como no sistema. E futuramente, mudando a plataforma do sistema, não vai ser preciso mexer no banco de dados.

Estrutura do banco
O banco de dados possui tabelas de:
LOTE, todos os produtos são lidos a partir de um número de lote.
EMPRESA, a empresa que esta lendo o malote (caso haja mais de uma empresa usando o mesmo sistema).
ORIGEM e DESTINO, ex: 2100 – SP CAPITAL para 2399 – RJ CAPITAL (Uso a mesma tabela para origem e destino).
LEITURA, onde fica registrada a passagem do malote.

Para o exemplo, vou usar esta estrutura, alterando o nome dos campos para nomes mais apropriados.
Para o primeiro tópico, vou falar sobre rule.

Rule
O comando CREATE RULE cria uma regra para ser aplicada a uma tabela ou visão específica. O comando CREATE OR REPLACE RULE cria ou substitui uma regra existente com o mesmo nome para a mesma tabela.
As RULES (regras) permitem executar uma ação alternativa em: inclusão, alteração, exclusão e seleção (somente em caso de visões).
Em outras palavras, uma regra faz com que sejam executados comandos adicionais quando é executado um determinado comando em uma tabela.
As regras são executadas antes do início da execução de um comando. Se em alguma situação você desejar uma operação que dispare um evento de forma independente para cada linha da tabela, estamos falando de um gatilho e não de uma regra.
É importante saber que as regras não fazem parte do SQL padrão, mas são implementadas pelo Postgresql.
Para o exemplo, vou criar duas tabelas, que vou chamar de tb_main e tb_hist. A tb_main será responsável pelo registro da primeira passagem do malote e a tb_hist será responsável pelas demais passagens do malote ate o destino final, como mostra a Listagem 1.

Listagem 1. Script das tabelas tb_main e tb_hist
CREATE TABLE tb_main (
codtbmain    integer not null,    – código da tabela
codtblote    integer not null,    – código do lote
codtbprod    integer not null,    – código do produto
codorigem    integer not null,    – código origem do produto
coddestno    integer not null,     – código do destino do produto
codbarras    varchar (30) not null,– código de barras
dtatbmain    date,            – data da entrada

CONSTRAINT codtbmain_pkey PRIMARY KEY (codtbmain) –- chave primaria
);

CREATE TABLE tb_hist (
codtbhist    integer not null,    – código da tabela
codtblote    integer not null,    – código do lote
codtbprod    integer not null,     – código do produto
codorigem     integer not null,    – código origem do produto
coddestno    integer not null,     – código do destino do produto
codbarras     varchar (30) not null,– código de barras
dtatbhist    date,            – data da passagem do produto
hratbhist     time,            – hora da passagem

CONSTRAINT codtbhist_pkey PRIMARY KEY (codtbhist) –- chave primaria
);

Para garantir que o produto só seja registrado uma única vez na tabela principal, é necessário criar uma unique na tabela principal (tb_main), que vai ser: código do produto (codtbprod) e o código de barras do produto (codbarras), de acordo com o código abaixo:

CREATE UNIQUE INDEX unqtb_main ON tb_main (codtbprod,codbarras);

Ou seja, o produto só será gravado na tabela principal uma única vez, as demais passagens serão registradas na tabela de histórico.
Agora vem o ponto onde quero chegar: Para não termos que fazer o sistema verificar se o produto já existe ou não na tabela principal, antes de inserirmos o registro (o que causaria perda de desempenho), podemos criar uma regra (RULE) para fazer esta verificação no próprio banco, como mostra Listagem 2.

Listagem 2. Estrutura da rule rtb_main
CREATE RULE rtb_main AS ON INSERT TO tb_main    WHERE (EXISTS
(SELECT codtbprod, codbarras FROM tb_main
WHERE codtbprod = NEW.codtbprod AND codbarras = NEW.codbarras)
) DO INSTEAD (
INSERT INTO tb_hist (
codtbhist,
codtblote,
codtbprod,
codorigem,
coddestno,
codbarras,
dtatbhist,
hratbhist
) VALUES (
SELECT NEXTVAL(‘sequence’),    – cahave (pode ser um SEQUENCE)
NEW.codtblote,            – número do lote
NEW.codtbprod,            – código do produto
NEW.codorigem,            – código da origem
NEW.coddestno,            – código do destino
NEW.codbarras,            – código de barras
(SELECT CURRENT_DATE),        – seleciona data do banco
(SELECT CURRENT_TIME)        – seleciona hora do banco
)
);

Agora, sempre que ocorrer o evento INSERT na tabela principal (tb_main), a RULE rtb_main, vai verificar se o mesmo registro já existe nesta tabela. Se existir, então vai ser executado o bloco de comando INSTEAD, o comando anterior é ignorado (inserir na tabela principal “tb_main”) e então o registro vai para a tabela de histórico (tb_hist). Se não existir, o registro será gravado na tabela principal (tb_main) e também na tabela de histórico (tb_hist), para conseguir ter um controle total do rastreamento do produto.
Quando acionamos funções em PL/pgSQL, para tratamento de dados, algumas variáveis são criadas automaticamente, como é o caso do NEW e do OLD, que veremos a seguir. Essas duas variáveis guardam os parâmetros de comandos SQL ex: INSERT INTO tabela VALUES (parametro1, parametro2…).

NEW
Usa o tipo de dado RECORD, contem o parâmetro de uma nova linha para o banco de dados, é usado somente em casos de INSERT e UPDATE.

OLD
Também é do tipo RECORD, mas contem o parâmetro de uma linha antiga do banco de dados, e é usada somente em UPDATE e DELETE.

Existem muitas outras variáveis que o Postgresql cria em funções, mas para o exemplo, vou usar apenas NEW e OLD, veja abaixo algumas variáveis.

VARIAVEIS EM POSTGRESQL
TG_WHEN Tipo de dado text; uma cadeia de caracteres contendo BEFORE ou AFTER dependendo da definição do gatilho.

TG_LEVEL Tipo de dado text; uma cadeia de caracteres contendo ROW ou STATEMENT dependendo da definição do gatilho.

TG_OP Tipo de dado text; uma cadeia de caracteres contendo INSERT, UPDATE, ou DELETE informando para qual operação o gatilho foi disparado.

TG_RELID Tipo de dado oid; o ID de objeto da tabela que causou o disparo do gatilho.
TG_NAME Tipo de dado name; variável contendo o nome do gatilho realmente disparado.

Em ambas as tabelas, existe um campo chamado codtblote, que nada mais é do que um número que identifica o lote em que o produto é inserido. Isso é para ter um controle interno (gerar relatórios, pesquisar os produtos que estão em determinado lote, etc.).
Então, já que o numero de um lote será variável (para cada passagem do produto, o sistema vai gerar um numero de lote diferente), vamos criar mais uma regra, que agora vai atualizar o numero do lote codtblote, da tabela principal tb_main.
Pois assim, conseguiremos tirar os relatórios e pesquisas com um ganho maior em desempenho, devido à quantidade menor de registros que vão existir na tabela principal, como mostra a criação da regra na Listagem 3.

Listagem 3. Estrutura da rule rtb_hist
CREATE RULE rtb_hist AS ON INSERT TO tb_hist
DO UPDATE tb_main SET codtblote = NEW.codtblote
WHERE codtbprod = NEW.codtbprod AND codbarras = NEW.codbarras

Sempre que uma nova linha for inclusa na tabela de histórico, essa RULE vai fazer com que seja atualizado o número do lote (codtblote) na tabela principal (tb_main).
Para finalizar esta parte de RULE, vamos criar uma regra para o evento DELETE, que sempre que por algum motivo, um registro precise ser apagado durante o processo de rastreamento, o registro não saia da tabela principal (tb_main), para não perder sua referencia, mas sim da tabela de histórico.
Para este exemplo, vou usar como parâmetro o lote codtblote, para deletar somente o registro que foi lido naquele lote especifico. (ver Listagem 4).

Listagem 4. Estrutura da rule rtb_hist no evento ON DELETE.
CREATE RULE rtb_hist AS ON DELETE TO tb_main
DO INSTEAD
(DELETE FROM tb_hist WHERE codtbprod = OLD.codtbprod AND codbarras = OLD.codbarras AND codtblote = OLD.codtblote);

Nesta regra, esta sendo usada a variável OLD, pois estamos usando o evento DELETE. Podemos ler mais sobre essas variáveis na documentação oficial do Postgresql, na seção Links.

TRIGGER
As Triggers (gatilhos) são recursos dos bancos de dados que, executam funções no banco, quando um determinado evento ocorrer na tabela em que a trigger estiver associada. Diferentemente das regras, os gatilhos podem ser acionados antes (before) ou depois (after) de alguma ação de insert, update e delete.
Veja a sintaxe abaixo:

CREATE TRIGGER (nome_trigger) (AFTER ou BEFORE) (ação INSERT, UPDATE ou DELETE)
ON (nome_tabela)FOR EACH ROW EXECUTE PROCEDURE (nome_da_function())

Quando um gatilho esta marcado FOR EACH ROW, o mesmo é chamado uma vez para cada linha que a operação modificar. Por exemplo: imagine que você precise inserir dez registros em uma tabela. Isso vai fazer com que todos os gatilhos ON INSERT sejam chamados dez vezes, uma vez para cada linha.

Se por ventura existir vários gatilhos do mesmo tipo, para o mesmo evento, eles serão disparados em ordem alfabética.

Os gatilhos são muito usados para tratamento de dados ou para efetuar alguma operação em tabelas, por exemplo: imagine que você tenha um sistema, que em uma determinada rotina, para deletar um registro, seja preciso gravar o mesmo em uma tabela de histórico.
Para resolver este problema, basta criar uma função para gravar este registro na tabela de histórico, e criar um gatilho para que sempre que o evento DELETE ocorra nesta tabela, o registro seja gravado no histórico.
Ou por exemplo, você precisa fazer uma validação em certa coluna da tabela para ver se o dado é um integer ou uma string para evitar que o banco gere uma mensagem de erro durante o processo. Para este caso, crie uma função que verifica se o dado é integer ou string e depois criar uma trigger chamando esta função no evento BEFORE INSERT.
Um gatilho é uma espécie de procedimento armazenado (stored procedures), mas não o chamamos como exemplo “SELECT minha_funcao ()”, mas sim sempre que um evento de insert, update e delete ocorrer na tabela.
Como vamos ver no próximo tópico, o que vai distinguir uma function de uma stored procedure, vai ser o tipo de dado que ela vai retornar que especificamos no momento que criamos a function, que no caso vai ser uma trigger.

FUNCTION
O comando CREATE FUNCTION cria uma função e o comando CREATE OR REPLACE FUNCTION, cria ou substitui uma função já existente.
Sempre que uma função é removida e recriada, essa função não será mais a mesma entidade que era antes. Nesse caso, vai ser necessário remover as regras, visões e gatilhos que fazem referência à função antiga. Sempre que por algum motivo, precisarmos modificar uma função, é aconselhável utilizar o comando CREATE OR REPLACE FUNCTION, pois, com isso, apenas a definição da função é modificada, sem invalidar os objetos que fazem referência à mesma.

Devido à grande flexibilidade do Postgresql, ele permite escrever funções em SQL, C ou outra linguagem procedural definida pelo usuário.
Agora vamos imaginar que antes de inserir na tabela principal do exemplo tb_main, temos que checar se o código de barras (codbarras) tem exatas 30 posições e que o número do lote (codtblote) não esta NULL.
Para fazer isto, vou criar uma função que vai fazer esta verificação, e se houver inconsistência nos dados, ela vai retornar com uma mensagem e cancelar a gravação de uma nova linha na tabela “tb_main”, como pode ser visto na Listagem 5.

Listagem 5. Função para verificar código de barras e lote
CREATE OR REPLACE FUNCTION ftb_main() RETURNS trigger
AS
$$
BEGIN
IF length(NEW.codbarras) < 30 THEN
RAISE EXCEPTION ‘CAMPO DEVE TER 30 POSIÇÕES!!’;
END IF;
IF NEW.codtblote IS NULL THEN
RAISE EXCEPTION ‘O LOTE ESTA VAZIO!!’;
END IF;
END;
$$
LANGUAGE ‘plpgsql’;

– para chamar esta função vou criar um gatilho

CREATE TRIGGER tg_tbmain BEFORE INSERT ON tb_main
FOR EACH ROW EXECUTE PROCEDURE ftb_main();

As funções também podem ser usadas para tratamento de exceções, por exemplo: imagine que por algum motivo, não podemos usar a primeira regra, definida na Listagem 3. Então vamos lembrar que no início do artigo criamos uma unique (Listagem 2) que define o código do produto (codtbprod) e o código de barras (codbarras) como único.
A partir desta unique, vou criar uma função que vai fazer um processo similar ao que nossa primeira regra fazia. A nova função vai “tentar” inserir uma nova linha na tabela principal, mas se essa nova linha tiver o mesmo código de produto e código de barras, o Postgresql vai gerar uma exceção de unique e vai interromper a ação.
Com o tratamento de erros vou conseguir “pegar” este erro gerado pelo Postgresql e gerar uma ação do tipo INSTEAD similar ao da regra, de acordo com a Listagem 6.

Listagem 6. Tratamento de exceção usando uma função
CREATE OR REPLACE FUNCTION func_tbmain(integer,integer,integer,integer,varchar(30)) RETURNS text
AS
$$
DECLARE
codlote ALIAS FOR $1;
codprod ALIAS FOR $2;
codorig ALIAS FOR $3;
coddstn ALIAS FOR $4;
codbras ALIAS FOR $5;
BEGIN
INSERT INTO tb_main (codtbmain,codtblote,codtbprod,codorigem,
coddestno,codbarras,dtatbmain)
VALUES ((SELECTSEXTVAL(’sequencial’)),codlote,codprod,
codorig,coddstn,codbras,(SELECT CURRENT_DATE));

INSERT INTO tb_hist (codtbhist,codtblote,codtbprod,codorigem,
coddestno,codbarras,dtatbhist,hratbhist)
VALUES ((SELECT NEXTVAL(’seqtb000′)),codlote,codprod,
codorig,coddstn,codbras,(SELECT CURRENT_DATE),(SELECT CURRENT_TIME));

RETURN codbras;

EXCEPTION
WHEN unique_violation THEN
INSERT INTO tb_hist (codtbhist,codtblote,codtbprod,codorigem,
coddestno,codbarras,dtatbhist,hratbhist)
VALUES ((SELECT NEXTVAL(’sequencial’)),codlote,codprod,
codorig,coddstn,codbras,(SELECT CURRENT_DATE),(SELECT CURRENT_TIME));

UPDATE tb_main SET codtblote = codlote WHERE codtbprod = codprod AND codbarras =    codbras;
RETURN codbras;
END;
$$
LANGUAGE ‘plpgsql’;

– para chamar esta função, vou usar o SELECT nome(passando os parametros)

SELECT func_tbmain(parametro1,parametro2,parametro3…)

Se durante o processo de inclusão não ocorrer nenhum erro de unique_violation, a função vai simplesmente gravar uma nova linha na tabela tb_main e depois na tb_hist e vai passar direto para a instrução END, ignorando assim tudo que vem depois do EXCEPTION da função.
Mas se ocorrer exceção, o primeiro bloco da função é ignorado e o controle passa para a lista de EXCEPTION, executando todo o bloco até o fim.

Se dentro de um bloco de comando de uma função, não existir o EXCEPTION e um erro fosse capturado, a função seria interrompida.
Com o EXCEPTION na função, esse mesmo erro seria capturado, o bloco de comandos acima do EXCEPTION seria ignorado e o bloco de comando logo abaixo do EXCEPTION seria executado, evitando assim que a função fosse interrompida.

CONCLUSÃO
Neste artigo vimos uma pequena introdução para regras, funções e gatilhos no Postgresql. Claro que há muito mais coisas para serem vistas a esse respeito, mas fica o registro para as pessoas que iniciam nesta área, e também para os que querem migrar ou desenvolver aplicações.

Links
Documentação do Postgresql
http://pgdocptbr.sourceforge.net/pg82/index.html
Tutorial
http://pgdocptbr.sourceforge.net/pg82/tutorial.html
Referencias
http://pgdocptbr.sourceforge.net/pg82/reference.html

Rodrigo Ibraim

PGOpen Consultoria

Segue abaixo um script(Shell) simples, mas funcional de automatização da rotina de Backup e Vacuum no PostgreSQL.

passos:

1 – Vamos criar o arquivo abaixo e dar a ele o nome de Backup.sh

________________________________________________________________________________

#!/bin/bash
clear
echo “#################################”
echo “# Bem Vindo a Sistema de Backup              #”
echo “# Versao 1.0                                                    #”
echo “# Qui Jun 09 04:01:18 BRT 2009                   #”
echo “#################################”
SUDO=’sudo -u postgres’
BANCO=`$SUDO psql -l | grep .’db’ | cut -f1 -d ‘|’`
DIRDEST=’/mnt/bkbanco/’
for DATABASE in $BANCO; do
echo “Iniciando Backup do Banco “$DATABASE
$SUDO pg_dump -Fc $DATABASE > ${DIRDEST}${DATABASE}`date +%d-%m_%H%M`’.sql’
done
echo “Fim do Backup”
SUDO vacuumdb -a -z -f

________________________________________________________________________________

2 – Vamos tornar nosso script um arquivo executável digitando o comando;

chmod +x  backup.sh

3 – Deixaremos nosso backup automático usando a ferramenta de agendamento de tarefas CRON

Digitamos:

crontab -e

Dentro do arquivo basta adicionar a seguinte regra:

0 23  * * 1-6 /mnt/backup.sh  # aqui determinamos que o backup será executado as 23 horas de segunda à sábado.

Pronto, agora temos uma rotina de backup agendada com o cron, os arquivos serão gerados de forma compacta pois utilizamos a sintaxe -Fc, para finalizar vamos mostrar a forma de restaurar o backup gerado:

pg_restore -d [banco] [arquivo_de_backup].sql | psql -e [banco]

O PostgreSQL tem algumas vantagens com relação ao MySQL, como integridade referencial e suporte a transações NATIVO. O MySQL também oferece esses recursos, mas não é NATIVO, mas usando as tabelas do tipo InnoDB que não é da equipe MySQL AB. Fora que para tirar proveito desse tipo de tabela o MySQL precisa ser mais bem configurado, para reservar espaço para as tabelas, entre
outras providências.
Fonte: http://listas.softwarelivre.org/pipermail/psl-go/2004-December/000325.html

Lista completa – http://www.postgresql.org/about/sponsors
Algumas Empresas que usam o PostgreSQL (internacionais)
- Apple
- BASF
- Cisco
- OMS (Organização Mundial de Saúde)

Algumas Empresas que usam o PostgreSQL (nacionais)
- FAB (Força Aérea Brasileira)
- Prefeitura Municipal de Sobral
- Vivo
- DNOCS
- DETRAN do Ceará

Suporta conjuntos de caracteres internacionais, codificação de caracteres multibyte, Unicode e sua ordenação por localização, sensibilidade a caixa (maiúsculas e minúsculas) e formatação.

É altamente escalável, tanto na quantidade enorme de dados que pode gerenciar, quanto no número de usuários concorrentes que pode acomodar. Existem sistemas ativos com o PostgreSQL em ambiente de produção que gerenciam mais de 4TB de dados.  Alguns limites do PostgreSQL estão incluídos na tabela abaixo.

Roda em todos os grandes sistemas operacionais, incluindo GNU/Linux, Unix (AIX, BSD, HP-UX, SGI IRIX, Mac OS X, Solaris, Tru64), e MS Windows. É totalmente compatível com ACID, tem suporte completo a chaves estrangeiras, junções (JOINs), visões, gatilhos e procedimentos armazenados (em múltiplas linguagens).

Inclui a maior parte dos tipos de dados do ISO SQL:1999, incluindo INTEGER, NUMERIC, BOOLEAN, CHAR, VARCHAR, DATE, INTERVAL, e TIMESTAMP.  Suporta também o armazenamento de objetos binários, incluindo figuras, sons ou vídeos.  Possui interfaces nativas de programação para C/C++, Java, .Net, Perl, Python, Ruby, Tcl, ODBC, entre outros.

É muito fácil encontrar serviços de hospedagem de sites que oferecem em seus planos os Sistemas Gerenciadores de Banco de Dados (SGDB) MySQL e PostgreSQL, embora isso seja mais comum com o primeiro. Como esses SGBD não são usados apenas na internet, talvez seja de seu interesse utilizá-los em seus projetos de software, uma vez que cada um é dotado de vantagens interessantes, como a gratuidade de uso. Para ajudá-lo a escolher o melhor para sua aplicação, este artigo apresenta as principais características de ambos, começando com o MySQL. Para tanto, é recomendável que você tenha algum conhecimento sobre os conceitos de bancos de dados.

Alguns termos

Mesmo aquelas pessoas que já trabalham com banco de dados podem ficar “perdidas” no meio de tantos nomes de recursos. Assim, para facilitar a compreensão, segue uma lista com uma breve explicação sobre os recursos mais importantes:

- Referential integrity: também conhecido como “integridade referencial”, esse recurso consiste em restrições ou regras existentes para uma correta inserção de dados, por exemplo, para impedir que uma tabela seja preenchida sem que isso ocorra em outra;

- Schemas: recurso que permite cruzar informações em um mesmo banco de dados, mas em estruturas diferentes;

- SQL: sigla para Structured Query Language, é uma linguagem utilizada em bancos de dados relacionais;

- SSL: sigla para Secure Sockets Layer, consiste em um protocolo para a troca segura de informações;

- Stored procedures: esse recurso consiste em comandos SQL “guardados” no servidor para, por exemplo, executar tarefas repetitivas, evitando que um cliente tenha que executá-las constantemente;

- Transactions: também conhecidas como transações, as transactions são instruções executadas em um bloco designado por parâmetros que indicam seu início e seu fim;

- Triggers: também chamados de gatilhos, os triggers são recursos que permitem o acionamento de uma seqüência de comandos logo em seguida ou logo após um evento;

- Views: os views consistem em um tipo de tabela virtual formada por campos extraídos de uma tabela “verdadeira”, facilitando o controle sob os dados acessados.

O banco de dados MySQL

MySQL é um dos sistemas de gerenciamento de banco de dados mais populares que existe e, por ser otimizado para aplicações Web, é amplamente utilizado na internet (inclusive aqui no InfoWester). É muito comum encontrar serviços de hospedagem de sites que oferecem o MySQL e a linguagem PHP, justamente porque ambos trabalham muito bem em conjunto.

Outro fator que ajuda na popularidade do MySQL é sua disponibilidade para praticamente qualquer sistema operacional, como Linux, FreeBSD (e outros sistemas baseados em Unix), Windows e Mac OS X. Além disso, o MySQL é um software livre (sob licença GPL), o que significa que qualquer um pode estudá-lo ou alterá-lo conforme a necessidade.

Entre as características técnicas do SGBD MySQL, estão:

- Alta compatibilidade com linguagens como PHP, Java, Python, C#, Ruby e C/C++;

- Baixa exigência de processamento (em comparação como outros SGBD);

- Vários sistemas de armazenamento de dados (batabase engine), como MyISAM, MySQL Cluster, CSV, Merge, InnoDB, entre outros;

- Recursos como transactions (transações), conectividade segura, indexação de campos de texto, replicação, etc;

- Instruções em SQL, como indica o nome.

Até o momento em que este artigo era escrito, o MySQL estava na versão 5.0 (mais precisamente, 5.0.26). Em relação à versão 4.0, houve acréscimo de vários recursos e melhorias importantes, como:

- Triggers;

- Stored procedures;

- Sub-selects;

- Suporte total ao Unicode;

- INFORMATION_SCHEMA (para armazenamento do dicionário de dados);

- Server side cursors;

- Suporte a SSL;

- Melhoria no tratamento de erros.

O MySQL surgiu na Suécia pelas mãos de três colegas: Allan Larsson, David Axmark e Michael Monty Widenius. Trabalhando com base de dados, eles sentiram a necessidade de fazer determinadas conexões entre tabelas e usaram o mSQL para isso. Porém, não demorou para perceberem que essa ferramenta não lhes atendia conforme o necessário e passaram a trabalhar em uma solução própria. Surgia então o MySQL, cuja primeira versão foi lançada no ano de 1996.

Um fato importante a ser destacado sobre o MySQL é que esse SGBD também possui uma licença comercial, isto é, paga. Neste caso, é possível obter suporte diferenciado dos desenvolvedores.

Vale ressaltar também que, em fevereiro de 2008, o MySQL foi comprado pela Sun Microsystems, que pagou a quantia de 1 bilhão de dólares pela aquisição. Mais informações sobre essa transação neste link (em inglês).

O banco de dados PostgreSQL

PostgreSQLO sistema gerenciador de banco de dados PostgreSQL teve seu início na Universidade de Berkeley, na Califórnia, em 1986. À época, um programador chamado Michael Stonebraker liderou um projeto para a criação de um servidor de banco de dados relacionais chamado Postgres, oriundo de um outro projeto da mesma instituição denominado Ingres. Essa tecnologia foi então comprada pela Illustra, empresa posteriormente adquirida pela Informix. Porém, mesmo diante disso, dois estudantes de Berkeley (Jolly Chen e Andrew Yu) compatibilizaram o Postgres à linguagem SQL. Este projeto recebeu o nome de Postgres95.

Em 1996, quando o projeto estava estável, o banco de dados recebeu o nome de PostgreSQL. No entanto, enquanto ainda possuía o nome Postgres95, o banco de dados teve várias mudanças. O seu código foi totalmente revisado e a linguagem SQL foi definida como padrão.
Tecnicamente falando, o PostgreSQL é um banco de dados relacional e orientado a objetos. Um de seus atrativos é possuir recursos comuns a banco de dados de grande porte, o que o deixa apto a trabalhar, inclusive, com operações de missão crítica. Além disso, trata-se de um banco de dados versátil, seguro, gratuito e de código aberto (disponível sob uma licença BSD).

Entre suas características, tem-se:

- Compatibilidade multi-plataforma, ou seja, executa em vários sistema operacionais, como Windows, Mac OS X, Linux e outras variantes de Unix;

- Compatibilidade com várias linguagens, entre elas, Java, PHP, Python, Ruby, e C/C++;

- Base de dados de tamanho ilimitado;

- Tabelas com tamanho de até 32 TB;

- Quantidade de linhas de até 1.6 TB ilimitada;

- Campos de até 1 GB;

- Suporte a recursos como triggers, views, stored procedures, SSL, MVCC, schemas, transactions, savepoints, referential integrity e expressões regulares;

- Instruções em SQL, como indica o nome.

No momento em que este artigo era escrito, o PostgreSQL estava na versão 8.1.

MySQL x PostgreSQL

MySQL ou PostgreSQL, qual usar? Ambos são muito bons e não fazem feio diante das alternativas pagas. Além disso, possuem recursos e vantagens em comum, o que significa que, para a maioria das aplicações, ambos podem ser usados. Na verdade, o correto não é tentar descobrir qual é o melhor, mas em que situação um ou outro deve ser utilizado.

O PostgreSQL é otimizado para aplicações complexas, isto é, que envolvem grandes volumes de dados ou que tratam de informações críticas. Assim, para um sistema de comércio eletrônico de porte médio/alto, por exemplo, o PostGreSQL é mais interessante, já que esse SGBD é capaz de lidar de maneira satisfatória com o volume de dados gerado pelas operações de consulta e venda.

O MySQL, por sua vez, é focado na agilidade. Assim, se sua aplicação necessita de retornos rápidos e não envolve operações complexas, o MySQL é a opção mais adequada, pois é otimizado para proporcionar processamento rápido dos dados e tempo curto de resposta sem exigir muito do hardware. Se você precisa, por exemplo, de um banco de dados para armazenar o conteúdo do seu site, de seu fórum ou necessita manter um cadastro de usuários de um portal, o MySQL “serve como uma luva”, pois tais aplicações não necessitam dos recursos avançados que o PostgreSQL oferece.

Para escolher um destes dois SGBD, procure entender bem quais recursos sua aplicação precisa. Tente estimar o volume de dados, avalie o hardware disponível, certifique-se das funcionalidades necessárias e, posteriormente, procure por informações mais detalhadas do MySQL e do PostGreSQL. Se sua aplicação for simples – principalmente se for algo ligado à internet -, não é preciso pensar muito: o MySQL é uma escolha satisfatória, pois é facilmente encontrado em serviços de hospedagem.

Todavia, há situações em que tanto o MySQL quanto o PostgreSQL serão boas escolhas. Nesses casos, é recomendável fazer testes com ambos e avaliar qual oferece mais vantagens à aplicação.

Finalizando

Um banco de dados pode ser a diferença entre ter e não ter um negócio, seja ele de qualquer porte. Por isso, a escolha deve ser bem feita e aspectos como desempenho, recursos, documentação e suporte devem ser considerados. Em todos esses pontos o MySQL e o PostgreSQL são excelentes, por isso, a escolha entre um deles só depende de sua aplicação.