O Movimento Revolucionário PostGreSQL
Por Natanael Simões | 03/07/2009 | TecnologiaImagine um mundo onde você seja livre. Nada melhor do que você criar sua receita de bolo e compartilhar com os amigos, e um desses amigos, a partir desta receita, criar um novo sabor de bolo. Você acabou de gravar o seu nome plaquinha dos "boleiros".
No mundo da Informática funciona da mesma maneira que a pequena metáfora apresentada acima. Ou deveria. O programador, principalmente enquanto iniciante, tem diversas dúvidas quanto em que banco de dados desenvolverá suas soluções. A escolha parte de algumas premissas básicas, como quais ferramentas o SGBD oferece, com qual o volume de dados a solução se deparará, entre outras. Mas isto já é discussão para outro artigo.
PostGreSQL é um Sistema Gerenciador de Banco de Dados (SGBD) que, nas mãos das pessoas certas, torna-se uma arma mortal. Adiante abordarei sobre diversos pontos em que o PostGre pode ser considerado superior a outros no mercado:
- Open Source
Sobre o PostGre há uma licença GPL que garante a publicação de seu código-fonte abertamente, que em termos técnicos chamamos de Open Source, ou da tradução, "Código Aberto". Isto quer dizer que o PostGre nada mais é do que um bolo pronto em que o usuário sabe exatamente o que foi usado como ingrediente(ENTRADA), sabe como ocorrem todos os passos de preparação(PROCESSAMENTO) e, consequentemente, o resultado final(SAÍDA), e não há restrições quanto a edição, exclusão ou inserção de rotinas, funções, entre outros. Nem sempre se achará uma aplicação que dê 100% daquilo que é necessário, logo alterações serão necessárias para que a demanda seja atendida.
Por ser Open Source, há diminuição visível nos gastos com licenças e até mesmo na manutenção. Geralmente, o suporte é feito pelos próprios usuários através de fóruns relacionados ao PostGre e pela documentação que, apesar de ser extensa, possui muita informação que dá suporte ao mantenedor do SGBD, como rotinas de otimização e backups.
Outra preocupação constante é que, geralmente, os SGBDs, assim como muitas aplicações, têm seu código fechado impedindo uma visão estendida daquilo que ocorre: é uma caixa preta, onde se dá uma entrada de acordo aos padrões estabelecidos para aquela caixa, onde a mágica acontece, e "PLIM!", ali está seu resultado, pronto para ser usado. Não querendo julgar, pois o criador sempre tem direito sobre sua criação. Abrir o código ou não é decisão dele.
- CPU-Bound
O PostGre tem grande poder de processamento. É o segundo, depois do Oracle, em processamento de consultas complexas e longas. Cada consulta gera uma transação no banco de dados, que vai desde a análise da sintaxe na aplicação do cliente até o retorno dos registros, e esta transação tem tempo de CPU distinta para cada SGBD. O tempo e os recursos que o PostGre consomem são altos, mas os resultados compensam. Você poderia escrever uma longa sequência de JOINs no MySQL e iterações entre as tabelas filhas de um determinado ID, o que implicaria em várias consultas, mas no PostGre faz-se a solicitação destes registros em apenas uma consulta que é retornada em apenas alguns milissegundos.
- Orientado a Objetos
Este aspecto foi, de longe, o que mais me surpreendeu. Até antes de eu conhecer o PostGreSQL, em minha vida acadêmica, já escutava rumores de bancos de dados Orientados a Objeto, mas que ainda estava em desenvolvimento e que quase ninguém usava. Me perguntava, com freqüência: -Por que temos que estudar uma Linguagem Orientada a Objetos se quando usarmos um banco pra persistir os dados teremos pensar Estruturado novamente? Foi aí que eu conheci o PostGre xD. Que dia lindo foi aquele... na aula o professor do mini-curso da 2ª InfoUnir, em Porto Velho,mostrou a possibilidade de criar Schemas, uma espécie de classe e, dentro da classe, coloca-se as tabelas relacionadas a ela. Mas depois de alguns dias procurei pela documentação do PostGre para pesquisar a tabela de erros e construir um depurador de banco de dados para minhas aplicações futuras. Foi aí que eu vi, chapado, na minha cara: "POSTGRE É UM BANCO DE DADOS RELACIONAL E ORIENTADO A OBJETOS". Eu pirei! Já perto vi um link indicando um tutorial de como fazer HERANÇA. E eu tava no meio da aula na faculdade esse dia. Aí sim eu fiquei louco. Só faltou eu virar uns mortais na sala. Mas continuemos com o artigo, isso está ficando nostálgico.
Na documentação do PostGre dá-se o seguinte exemplo:
CREATE TABLE cidades (
nometext,
populacaoreal,
altitudeint
);
CREATE TABLE capitais (
estadochar(2)
) INHERITS (cidades);
Perceba que a cláusula INHERITS faz a herança de 'cidades' para 'capitais', pois toda capital é uma cidade, correto? A tabela 'capitais' será preenchida de acordo com a 'cidades', mas com um campo adicional. Quando houver execução de "SELECT * FROM cidades", as capitais constaram nos registros. Lembre-se de que 'capitais' também são 'cidades'! Para seleção apenas de uma das tabelas, usa-se a cláusula ONLY, com em "SELECT * FROM ONLY cidades" que retornará APENAS as cidades que não são capitais.
- Multilinguagem em Functions e Triggers
Quando houver necessidade de escrever processos específicos e repetitivos, de rodar rotinas quando uma determinada tabela é atualizada, dentre outras situações em que, geralmente, não há intervenção do usuário, as FUNCTIONS e TRIGGERS podem ser escritas em C, SQL ou PGplSQL, que é uma linguagem interna do PostGre.
PS: Open Source também será abordado em breve de acordo com meu cronograma de artigos.
Muitas vezes, os SGBDs, assim como muitas aplicações, têm seu código fechado impedindo uma visão estendida daquilo que ocorre: é uma caixa preta, onde se dá uma entrada de acordo aos padrões estabelecidos para aquela caixa, onde a mágica acontece, e PLIM!, ali está seu resultado, pronto para ser usado.
- Recursos Disponíveis
Roda na maioria dos sistemas operacional do mercado, como Windows, Linux, Mac e variações de Unix. Além de usar C para construção de suas funções, PostGre também tem suporte em PL/Perl, PL/PHP, PL/Python, PL/Ruby, entre outros . Isto que vou dizer agora chega a ser assustador. !SE VOCÊ JÁ ESTÁ COM MEDO PARE DE LER AGORA!. O PostGre tem bases de dados com tamanho ilimitado. As tabelas pode ocupar espaço em disco de até 32TB, cada linha, até 1.6TB e campos de até 1GB. Ele também é compatível com os padrões de dados SQL2003 e há possibilidade de criar novos tipos de dados.
E, para terminar este artigo extenso, a característica #17 do artigo "17 características do PostgreSQL que fazem falta no Oracle" publicado na PgOpen:
"Você já viu um artigo com uma comparação entre desempenho do PostgreSQL e o Oracle? Não? E provavelmente não verá. A Oracle pode processar qualquer um que publique testes de desempenhos comparativos com o Oracle sem a sua autorização. Isto faz parte do licenciamento do Oracle. Assim é fácil dizer que é mais rápido sempre! Aliás, vou te dizer que o PostgreSQL pode ser utilizado em projetos que envolvam tecnologia militar, pode ser utilizado por cubanos e iraquianos, brasileiros, etc, etc, etc…"
Algumas ferramentas e links importantes pra você começar a trabalhar com o PostGreSQL:
A EnterpriseDB disponibiliza material para estudo de PostGreSQL, além de treinamento para certificação ASSOCIATE e DBA. Há, em seu repositório, versões do PgSQL de acordo com a necessidade, do módulo básico, que vem apenas com o serviço de SGBD e o editor gráfico pgAdminIII, ao avançado, que possui até mesmo ferramentas de migração Oracle=>PgSQL.
Espécie de Wikipédia lotado de tutoriais e informações importantes de PgSQL
Comunidade Brasileira de PostGreSQL. Fórum de discussão, notícias mais recentes sobre o produto
REFERENCIAS BIBLIOGRÁFICAS
BERKUS, Josh. Projeto de aplicações para performance no PostgreSQL. Traduzido por Fábio Teles Rodrigues.
http://www.midstorm.org/~telles/2007/01/05/dicas-de-performance-em-aplicacoes-com-postgresql/
Artigo: 17 características do PostgreSQL que fazem falta no Oracle
http://www.pgopen.com.br/noticia.php?id=5
Artigo: Principais diferenças - PostgreSQL x MySQL http://www.infowester.com/postgremysql.php
Documentação PostGreSQL 8.0.0
http://www.postgresql.org.br/docs