Uma ode ao PostgreSQL

Klaus Peter Laube

31 de janeiro de 2013 - 6 minutos de leitura

O MySQL é um dos meus mais leais companheiros de projetos, desde os meus tempos de PHP até projetos mais recentes com o Python. A sua agilidade e facilidade são indiscutivelmente boas, tanto que renderam ao projeto um “domínio global” no ramo.

Hoje, sob “cuidados” da Oracle, o projeto tem causado certas desconfianças. A criação de um fork pelo autor original não ajudou, e isso abriu margem para um velho, confiável e simpático banco de dados: o Postgres.

Qual o motivo de começar um post sobre o Postgres falando do MySQL? Eu sempre me apoiei na “facilidade de uso” na hora de escolher entre os dois, e só recentemente me “obriguei” a experimentar o Postgres em alguns projetos. O resultado foi a total satisfação com a experiência, e a (surpreendente) conclusão que ele é tão fácil de mexer quanto o seu concorrente.

O que há de especial no Postgres?

O Postgres está sob a licença PostgreSQL License, muito similar a BSD e MIT, que nos permite o livre uso, cópia, modificação e distribuição. Assumidamente o “banco de dados open source mais avançado do mundo”, ele é conhecido pela sua estabilidade, servindo projetos de larga escala em todo o mundo. Embora eu nunca pude por à prova a sua confiabilidade e escalabilidade, o fato de ele ser usado como banco relacional pelo Heroku apresenta credenciais o suficiente.

Entre as diversas funcionalidades do Postgres, o suporte a operações assíncronas, o Full Text Search e o PostGIS se mostraram um bom diferencial para mim. Este último na verdade trata-se de uma extensão do Postgres (comprovando outra característica valiosa do banco, a extensibilidade), e tive a oportunidade de utilizá-lo em um projeto recente com Python e Django. Embora a sua implantação não tenha sido tão trivial quanto o esperado, o resultado atendeu completamente as expectativas.

Outro ponto que acho muito bacana no projeto, é o seu compromisso em seguir o padrão SQL. Atualmente (versão 9.2), o Postgres se compromete em atender o padrão ANSI-SQL: 2008. Acho muito bacana esse compromisso, principalmente se formos levar em consideração a quantidade de dialetos SQL que temos hoje em dia.

Junte isso tudo a facilidade de uso, e temos uma excelente ferramenta à nossa disposição. Ainda não está satisfeito? Então vamos falar um pouco sobre uma das características mais marcantes (e discutidas) do Postgres: O modelo objeto-relacional.

Objeto-Relacional?

A definição de banco de dados objeto-relacional da Wikipedia é a seguinte:

(...) é um sistema de gerenciamento de banco de dados (SGBD) semelhante a um banco de dados relacional, porém com um modelo de banco de dados orientado a objetos: objetos, classes e herança são suportados diretamente nos esquemas do banco de dados e na linguagem de consulta. Além disso, ele suporta extensão do modelo de dados com a personalização de tipos de dados e métodos.

Basicamente, um banco de dados objeto-relacional armazena os seus dados de forma “relacional”, mas é capaz de abstrair o seu acesso através de objetos, possibilitando assim a construção de operações mais complexas que podem envolver conceitos da orientação a objetos. No Postgres, tabelas, relacionamentos, restrições e triggers são considerados objetos.

Mas não são os “objetos” que vemos nas linguagens de programação. O termo “objeto” aqui é um pouco diferente (e eu diria até limitado), embora podemos encontrar heranças, polimorfismo e object ids. No caso do Postgres, o “objeto” de “objeto-relacional” está ligado a todos os aspectos citados anteriormente, mais a organização dos “recursos”, como na utilização de schemas, e na criação de tipos e manipulação de dados complexos.

Ou seja, você não verá uma notação como essa em uma query:

SELECT NOW().to_char('HH12:MI:SS');

E sim, a notação utilizando funções:

SELECT to_char(NOW(), 'HH12:MI:SS');

Mas em compensação, você verá que to_char é uma função polimórfica:

SELECT to_char(10.3333333, '99.99');

Se você não está satisfeito, e não se sente confortável com o termo “objeto” usado pelo Postgres, fique tranquilo… mais pessoas carregam esta angústia. Michael Stonebraker criou um esquema para identificar um ORDBMS, e partindo dele sou obrigado a concordar que o Postgres é de fato um banco objeto-relacional quando me deparo com o seguinte cenário:

CREATE TYPE inventory_item AS (
    name            text,
    supplier_id     integer,
    price             numeric
);

CREATE TABLE on_hand (
    item      inventory_item,
    count     integer
);

INSERT INTO on_hand VALUES (ROW('fuzzy dice', 42, 1.99), 1000);
INSERT INTO on_hand VALUES (ROW('cards', 42, 6.99)::inventory_item, 500);

Uma manipulação complexa, com tipos criados pelo próprio usuário, utilizando queries.

Considerações finais

O Postgres é poderoso! Disso eu não tinha dúvidas. Mas ficar mais próximo do banco me fez perceber o quanto ele pode agregar ao projeto. Se em um próximo projeto você estiver em dúvida, e achar que a utilização dele pode ser complicada, eu recomendo que experimente.

Até a próxima…

Referências

banco-de-dados ambiente-de-desenvolvimento postgres objeto-relacional