Bom… todos sabem que o Oracle possui uma miríade de recursos bacanas e interessantes. Alguns deles o PostgreSQL realmente não tem, e alguns eu acredito que nunca terá (até porquê a equipe do PostgreSQL tem uma visão diferente em vários pontos da Oracle). Não estou dizendo que o PostgreSQL é melhor que o Oracle ou vice versa… estou dizendo apenas que escolher um SGDB não é como escolher uma roupa para dar de presente. Não basta olhar a marca e se deslumbrar com comerciais fantásticos, shows de luzes e coquiteis luxuosos. Você tem que conhecer as funcionalidades de cada um e saber onde está entrando. E o que quero demonstrar aqui é que o PostgreSQL também revela suas qualidades! É comum pessoas perguntando sobre recursos que o PostgreSQL tem que o Oracle não tem… aqui vai uma pequena lista. Por favor sinta-se a vontade para acrescentar novos itens nos comentários.
- Readline: para quem está acostumado com o bash, sabe como é bacana poder utilizar algumas facilidades providas por esta maravilhosa biblioteca. Completar comandos e histórico de comandos são duas coisas que tornam a experiência em modo texto muito agradáveis. Eu sei que o SQLPLUS tem muitas funcionalidade interessantes, mas o psql é realmente uma ferramenta muito mais agradável devido ao uso do Readline e para mim isto significa perda de produtividade e aumento na curva de aprendizado do SQLPLUS.
- Maior flexibilidade com as linguagens com as PLs. O PostgreSQL tem suporte ao PL/pgSQL, está implantando o PSM e tem suporte a PL/Python, PL/Ruby, PL/PHP, PL/PERL etc. E ainda tem a possibilidade de cria-las no modo TRUSTED e UNTRUSTED. Isso é uma mão na roda e aproxima muito o time de desenvolvedores dos DBAs.
- LIMIT e OFFSET, estas duas cláusulas não fazem parte do padrão SQL, mas a maioria dos SGDBs implementam. Se você tiver que paginar páginas de uma consulta (coisa que você sempre deve fazer ao retornar mais de 100 linhas numa página web por exemplo) utilizando o ROWNUM, você verá que o mundo poderia ser mais simples.
- Uma das primeiras coisas que eu descobri quando comecei a utilizar o Oracle: você não pode criar uma tabela e colocar uma sequência como valor padrão para um campo. Isto é só um pequeno detalhe, mas convenhâmos, é bem prático utilizar um insert sem ter de lembrar o nome da sequência atrelada ao campo;
- O Dollar Quoting é uma característica do PostgreSQLque nos permite evitar situações incômodas onde precisamos escapar aspas simples e duplas. Quando se utiliza PL, isto pode se tornar um tanto incômodo. Além disso o Dollar Quoting é um bom aliado na luta contra o SQL Injection
- Algo irritante no Oracle é o nome atribuído a objetos criados implicitamente. Se você cria uma chave primária e não atribui um nome explicitamente, tanto o PostgreSQL quanto o Oracle atribuem um nome para a sua PK. Mas enquanto o nome atribuído pelo Oracle é algo como SYS1328909 o PostgreSQL utiliza nomes muito mais inteligentes, através de um padrão de nomenclaturas inteligível. Num ambiente de testes onde os desenvolvedores esqueçam de atribuir todos os nomes explicitamente, o caos passa a reinar rapidamente nos nomes de objetos do Oracle.
- Se você quer uma funcionalidade avançada que o PostgreSQL oferece, ela se chama GiST. O GiST é uma infraestrutura para a criação de novos típos de índices para novos tipos de dados. Com ele é possível criar aplicações com demandas muito específicas com um excelente desempenho sem muito esforço. É claro que não é qualquer um que vai utilizar isso (assim como não é qualquer um que utiliza uma série de funcionalidades avançadas do Oracle), mas o leque de opções que isto abre é enorme. Existem algumas implementações de índices utilizando o GiST prontos para você utilizar. Eles mostram o poder de adaptação que o PostgreSQL possui para demandas específicas.
- Conformidade com o padrão SQL2003. Sim… o Oracle possui diversas coisas estranhas como usar o VARCHAR2 ao invés de VARCHAR, não utiliza o as visões do catálogo de sistema padrão e inúmeras coisas estranhas que são heranças antigas do Oracle que parecem que não tem melhorado muito nas últimas versões. O tipo de dados TIMESTAMP por exemplo, só surgiu na versão 9i. O mais simples tipo de dados, o BOOLEAN simplesmente não existe no Oracle. Se você quer saber mais sobre isso, compare você mesmo a lista de compatibilidade do Oracle e do PostgreSQL.
- Melhor integração com o SO. Você já atualizou uma Distribuição Linux com um Oracle instalado? Prepare-se para muita dor de cabeça, pois o processo é no mínimo delicado. Para quem utiliza uma distribuição Linux como o Debian, isso mal passa pela cabeça do DBA. Você atuliza o SO junto com o PostgreSQL e pronto. Outra coisa interessante é que você pode utilizar os redirecionamentos do shell para jogar a saída de uma exportação direto na entrada de uma importação. Isso economiza tempo de disco. Na verdade o PostgreSQL se ajusta muito bem com o Padrão POSIX, enquanto a Oracle insiste em criar suas próprias regras como o OFA (Optimal Flexibe Architeture).
- Você pode subir um Oracle num 486?? O Oracle é pesado, um verdadeiro dragão devorador de recursos. A versão 11g que foi lançada recentemente pede um mínimo de 1GB de memória no servidor. O PostgreSQL é bem mais flexível neste sentido. Você pode subir um PostgreSQL para testes no seu próprio desktop em 2 minutos e já sair testando sem ter que se preocupar muito com isso. Eu particularmente chego a ter 2 ou 3 versões do PostgreSQL rodando no meu desktop sem problemas. Agora dê uma olhada no procedimento de instalação do Oracle e você verá porquê poucas pessoas sabem colocar ele no ar de maneira adequada!
- Suporte a um número maior de arquiteturas. Por incrível que pareça, o Oracle não roda no FreeBSD por exemplo. Vale a pena comparar as arquiteturas suportadas pelo Oracle e PostgreSQL.
- Independência de suporte. Todo mundo pergunta se o PostgreSQL tem suporte confiável no Brasil. Tem sim, não vou me pronunciar a favor de um ou outro aqui, mas temos empresas muito competentes aqui no Brasil. Mas alguém já se perguntou como é o suporte da Oracle??? Como eles são detentores do código fonte do Oracle, só eles podem lhe oferecer um contrato de suporte mais profundo. Pergunte a um DBA Oracle como é o suporte da Oracle e você irá se surpreender! Já no PostgreSQL você não encontra este problema, você pode escolher a empresa que vai lhe prestar suporte. Se você não gostou do suporte de uma empresa… chame outra! Está com medo de ninguém segurar o rojão quando um problema mais sério acontecer? Quem disse que a Oracle não vai lhe deixar na mão? Bom, quer conhecer o suporte da Oracle, saiba o que mais de 90% das pessoas conhecem por suporte é na verdade apenas o acesso ao Metalink. Mas suponhamos que você precise de algo um pouco específico mais onde o Oracle não lhe atende? Bom, o mais provável é que a Oracle lhe diga NÃO ou se você der sorte estará diante de um orçamento monstruoso. Se você precisar de algo diferente no PostgreSQL, você pode entrar em contato com qualquer um dos seus desenvolvedores (existem alguns no Brasil) e solicitar uma nova funcionalidade. Você vai pagar apenas as horas de desenvolvimento dele e se ele achar que a funcionalidade é importante, você provavelmente verá ela implementada na Próxima versão do PostgreSQL e nunca mais terá de se preocupar com isso. Acredite ou não, várias funcionalidades do PostgreSQL que você usa hoje, surgiram assim. Veja o exemplo dos SkyTools. Existem empresas menores que tem contratos de manutenção com desenvolvedores do PostgreSQL e utilizam versões modificadas com particularidades mais bizarras e funcionam sem problemas. Um detalhe… se você não gostar do desenvolvedor, você simplesmente contrata outro, uma vez que você não precisa estar amarrado a ele.
- Acesso aos desenvolvedores. Você já perguntou alguma coisa a um desenvolvedor do Oracle? No postgreSQL isso é tranquilo, basta entrar na lista de discussão dos desenvolvedores. Um exemplo de como isso pode ser útil é saber o que esperar das próximas versões. Todo o ciclo de desenvolvimento é transparente, você sabe o que será implementado na próxima versão, e o que estão querendo implementar nas próximas. Saber para onde o seu SGDB vai dá muita segurança para o DBA.
- Acesso aos paths de correção independente de pagar licenciamento. Todo mundo fica com o orçamento apertado durante algum tempo. Mas se você deixar de pagar o suporte da Oracle, prepare-se para ficar vulnerável. As atualizações só estão disponíveis para quem está com seus pagamentos em dia;
- Você não precisa fazer um curso sobre licenciamento antes de iniciar o uso do PostgreSQL. Independente do custo das licenças, saber quais recursos você vai precisar licenciar com a Oracle, é um verdadeiro tormento. A cada versão as opções de licenciamento mudam e um número maior de opções pagas separadamente são oferecidas. O Oracle Forms começou como uma ferramenta gratúita que numa nova versão passou a ser paga e hoje está sendo descontinuada. Muitos orçamentos estouram porquê no meio do projeto se descobre que uma funcionalidade importante não foi prevista no contrato de licenciamento. Isso quando você não instala opções não licenciadas sem querer. Para licenciar um Oracle, você deve começar lendo “Software Investment Guide” que é um documento de 61 páginas explicando quando uma licença se aplica ou não, dependendo da arquitetura de SGDB que você quer montar. Depois precisa conhecer a diferença entre as 5 versões básicas do Oracle: “Express Edition”, “Personal Edition”, “Standard Edition”, “Standard Edition One” e “Enterprise Edition”. Aí você vai ter que conhecer cada uma das 15 opções do Enterprise Edition que são licenciadas a parte e ver se você vai precisar de algumas delas no seu projeto. Depois disso você precisa conhecer as opções de licenciamento e definir a melhor métrica a ser utilizada: por processador ou por usuários nomeados. Pronto, agora é definir o número de licenças para a sua arquitetura dentro da métrica escolhida e multiplicar pelo custo da licença de cada componente que você vai comprar. Não esqueça de incluir no mínimo o suporte standard da Oracle que custa em média 20% do custo total das suas licenças ao ano. Este custo só lhe dá acesso ao metalink, que inclui uma base de conhecimento, acesso aos paths de correção e pedidos de suporte via web. Se você quiser um suporte de verdade, aquele que você acha que o PostgreSQL não tem então você vai ter que fazer um novo estudo de custos baseado no SLA desejado.
- Linux é Linux, não importa qual distribuição você utilize. O Oracle roda em qualquer distribuição Linux atual. Eu já utilizei por um bom tempo em Debian e fiquei muito satisfeito com o resultado. Mas se você deseja ter qualquer nível de suporte da Oracle, você só vai poder utilizar 3 ou 4 distribuições homologadas por eles (incluindo a versão da própria Oracle que é uma cópia do Red Hat). Isto não significa que estas são as melhores distribuições Linux do mercado (embora sejam muito boas). A questão é que você não pode escolher. Da mesma forma, não é qualquer hardware que você pode utilizar para para rodar o Oracle, tem que se um hardware homologado. Estes dias vi que a Oracle homologava algumas soluções de NFS fornecido por terceiros. Isto significava que se você comprasse uma solução de NFS de um dos parceiros homologados pela Oracle, eles lhe dariam suporte. Depois a Oracle desistiu da parceria e deixou de homologar estas soluções (pois ela lançou sua própria versão de NFS). Quem comprou a solução indicada pela Oracle simplesmente deixou de ter uma solução homologada, o que significa: nada de suporte para você.
- Poder publicar benchmarks! 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…
