Longe de criar problemas aqui, muito pelo contrário, frequento o blog e sou um “leigo” entusiasta sobre PostgreSQL, mas quando se fala em arquitetura de banco de dados (SGDB’s) ainda deixa os dois muito separadamente, essa é minha opinião.

Os pontos que você citou sobre a utilização do PostGreSQL em comparação aos recursos Oracle, estou de apoio em alguns que você citou, concordo em seu ponto de vista, mas será uma coisa grande para se discutir, pois suportar é uma coisa, trabalhar com eficiência é outra.

Sobre ACID, bom, isso também é um assunto que será extremamente extenso e longo, se analisar desde a criação dos conceitos, que vem desde a IBM Research, IEEE, ANSI e sobre os pontos de vista de profissioanais como Edy Codd, Chris Date e etc, o assunto é muito mais embaixo. Alguns trabalhos de Doutorado estão ainda pesquisando como realmente efetivar um RDBMS como 100% ACID. Mas não vem ao caso.

Explicando esse ponto:

12) Realmente eu não entendi. Para mim isto é muito mais uma questão de arquitetura da aplicação do que qualquer outra coisa.

O banco de dados Oracle poderá trabalhar com recursos nativos que contemplam essas políticas de auditoria, independente da aplicação ou camada de segurança, são produtos como Label Security, Database Audit e Database Vault.

14) Isso é uma questão de gosto. Eu realmente prefiro ficar longe disso. Não é uma tecnologia que me agrada, ainda mais com o péssimo hábito da Oracle de abandonar tecnologias, como o fez com o Forms e o Oracle Aplication Server.

Também concordo contigo! E o hábito do abandono de tecnologia, está muito voltado as aquisições da Oracle, praticamente um jogo igual ao SimCity… então, existe tecnologia que morre e nasce toda hora.

Sobre o ponto de vista:

“O Linux é software livre e é utilizado no mundo inteiro em missão crítica. As pessoas não utilizam o Linux pelo preço, utilizam pela confiança que ele tem. Existe muitas empresas sérias envolvidas com Software Livre. Existem excelentes profissionais envolvidas com Software Livre. Existem empresas prestando suporte de excelente qualidade para Softwares Livres. Não é outro universo não… melhor prestar mais atenção no mercado.”

Concordo sobre o Linux é utilizado em alguns ambientes de HA, sou defensor, praticamente, entusiasta e estou indo para o LPI sobre o assunto, mas acho que entendeu errado meu comentário, Linux seria apenas o SO, não implicaria sobre a utilização em uma solução de HA ou MMA, apenas citei, que em ambientes desse jeito Oracle vs PostGreSQL ainda são extremamente distintos, é sim um outro universo, e justamente por estar dentro dos projetos que acontecem aqui em São Paulo, onde fazemos as POC’s sobre a utilização dos mesmos, com DB2, SQL Server, PostGreSQL, MySQL Enterprise, Sysbase, Adabas e Oracle. Lhe confirmo, não dá ainda para comparar, talvez num futuro próximo com a ajuda da comunidade e um bom desenvolvimento do CORE, mas correrá o risco de virar PAGO.

Eu sei e vi que o PostGreSQL pode ser escalonado para grandes BD’s, em TeraBytes, vi isso na prática e seus desempenhos, mas ainda digo, ambiente de produção de alto nível, fica complicado administrar uma base em PostGreSQL.

E parabéns pelo Blog.

Abraços,
Rodrigo Almeida

Quanto ao restante… acho que você está comendo bola. E feio.

* O PostgreSQL já tem suporte ao Common Table Expresions a partir do 8.4;
* O PostgreSQL é o que tem maior frexibilidade quanto a criação de funções de agregação, tipos de dados e até tipo de índices. E não tem como bater isso. O PostgreSQL tem o código aberto. Por definição ele é aberto para qualquer um fazer o que quiser.
* Sim, o PostgreSQL também pode usar Java embutido. E um monte de outras linguagens também.
* Você pode criar visões materializadas no PostgreSQL sem muita dificuldade. Basta dar um pulo em http://pgfoundry.org. Mas é verdade que isto deveria estar nativo já. Era para vir no 9.0 mas ficou para o 9.1.
* O Dollar Quoting ajuda sim, e muito. Tanto é que tem outro comentário aqui mesmo dizendo que o Oracle já tem uma implementação análoga chama Q-quoting. E não é que foi você mesmo que postou?

6) O postgreSQL pode trabalhar com objetos binários também, sem nenhum problema.
7) O ASM é algo para lá de polêmico e a comunidade PostgreSQL tem um posicionamento firme: não queremos raw devices. A partir da versão 9, o PostgreSQL também tem suporte a Hot Stand By;
9) O PostgreSQL tem suporte ao C, Python, Perl, Tcl, PHP, R, Java, etc. Aqui é uma área em que o PostgreSQL lidera em larga margem qualquer outro SGDB;
10) O PostgreSQL é ACID com certeza. Inclusive tem implementação de MMVC;
11) O PostgreSQL também tem isso. Na versão 9 inclusive, vai ser muito mais fácil customizar estes parâmetros por Tablespace, facilitando o ajuste de desempenho para dispositivos de disco com velocidades diferentes. Se você lembrar dos novos discos ESSDs vai perceber que o PostgreSQL está muito bem aparelhado. Vale lembrar também que como a estrutura de armazenamento do PostgreSQL é mais simples, vários ajustes que atormentaram os DBAs do Oracle por anos nunca incomodaram;
12) Realmente eu não entendi. Para mim isto é muito mais uma questão de arquitetura da aplicação do que qualquer outra coisa.
13) O PostgreSQL implementou funções de XML na versão 8.3
14) Isso é uma questão de gosto. Eu realmente prefiro ficar longe disso. Não é uma tecnologia que me agrada, ainda mais com o péssimo hábito da Oracle de abandonar tecnologias, como o fez com o Forms e o Oracle Aplication Server.

Até aqui tudo bem. Não são todos que acompanham as funcionalidades de ambos os bancos. Eu mesmo só estou começando a utilizar o Oracle 11 agora que saiu a versão 11.2. Mas sobre serem universos diferentes, acho que você está enganado.

O Linux é software livre e é utilizado no mundo inteiro em missão crítica. As pessoas não utilizam o Linux pelo preço, utilizam pela confiança que ele tem. Existe muitas empresas sérias envolvidas com Software Livre. Existem excelentes profissionais envolvidas com Software Livre. Existem empresas prestando suporte de excelente qualidade para Softwares Livres. Não é outro universo não… melhor prestar mais atenção no mercado.

Muito bom o artigo, parabéns! Eu vou complementar um pouco a sua lista de itens e a do nosso amigo Rodrigo Hjort que fez ótimas observações no uso do Oracle com relação ao PostgreSQL, vamos a ela:

1) Possibilidade de Criptografia em backup (RMAN) e tablespace (11g);

2) Virtual Columns para as tabelas, para campos sumarizados (11g);

3) Database Replay;

4) Assistentes de ajuste de performance da instância e instruções sql por ADDM e ASH;

5) Possibilidade de utilização de Multi-Blocagem em Tablespaces (Ótimo para BI);

6) Trabalhar com Large Objects (CLOB, BFILE, BLOB e NLOB);

7) Produto Grátis: ASM;

Produto Pago: Data Guard;

9) Suporte ao Pro*C, Java e C integradas á suas procedures e packages.

10) Banco de dados ACID;

11) Parâmetros específicos de ajuste de I/O para cada hardware;

12) O banco de dados está preparado para as principais regulamentações, como SOX, PCI, HIPPA, JSOX e etc.

13) XQuery para trabalhar diretamente com estrutura SQl em arquivo XML e o XML toolkit;

14) PSP – PL/SQL Server pages, permite usas procedures Oracle diretamente para web;

15) Real Application testing.

Entre outros recursos, que o Oracle sabe trabalhar e que em ambientes de produção fazem a diferença. O ruim, SIM, é o preço, Licensas são caras, mão-de-obra especializada é cara e hardware é caro! Não tem como escapar disso.

NA MINHA OPINIÃO, geralmente eu não gosto de comparar entre um banco de dados Pago (Oracle, DB2, SQL Server, Sysbase e Informix) com os Open-Source (MySQL, PostgreSQL, Firebird e etc). Pois razões lógicas, tais como:

- Os bancos de dados pagos, tem equipes de suporte e central de conhecimento, que fortalece as próximas versões dos produtos.

- Possuem sim, especialistas e estudiosos envolvidos na compilação do seu CORE. Ajuda em muito.

- E outra, os bancos pagos são outro mundo comparados aos Open-Source.

Sobre os Open-Source:

-Sim, gosto muitos dos Open-Source, principalmente do PostGreSQL que oferece bons recursos de disponibilidade, ajustes de performance e técnicas de programação. Porém, são limitados de acordo com a necessidade da empresa.

- São ótimos, pois são gratuitos. Reduz meus custos de TI em quase 30%.

- É feito pela comunidade, melhor troca de experiência e benchmark que esse não existe. Porém, mesmo que grandes especialistas e engenheiros que trabalham nas grandes dos bancos de dados ajudem as comunidades a aprimorar os códigos, eles não possuem TEMPO para contribuir. O que faz termos mais problemas.

Como digo, são mundos distintos, porém, não escolha o ORACLE pq ele é modinha ou pq todos falam dele, escolha um banco de dados que esteja de acordo com a necessidade da sua empresa, sites WEB, é lógico vamos usar MySQL e PostGreSQL, está ótimo, até para pequenas aplicações.

Mas quando a necessidade muda, aí o mundo muda, quer ter um ambiente MMA (Maximum Availability Archicteture), então, tu tem dinheiro para colocar um Oracle, DB2 ou SQL Server..

Abraços,
Rodrigo Almeida

- SQL analítico (funções sobre janelas móveis) é uma grande sacada, que poupa séries de self-joins e múltiplos table e index scans. Há também connect by loops e with clause com recursividade que eliminam necessidade de chavear contexto e ter I/O e tráfego de rede adicionais ao ser obrigado a usar PL em processamentos de dados complexos.

- É possível criar funções de agregação (SUM, AVG, MIN) customizadas, assim como funções analíticas custom, que são absurdamente eficientes e rápidas. Acho que o Postgres tem planos de disponibilizar analytics e with clause comum (sem recursividade) na versão 8.4.

- Pode-se usar procedures em Java para simplificar integração e em C também, para casos de processamento mais cpu-bound do que I/O bound, por exemplo. PL/SQL pode também ser mantida com compilação interpretada (estilo java) ou nativa, nos casos de processamento cpu bound.

- Outro recurso interessante é que pode-se usar views materializadas com sincronização automática em tempo de commit do banco, removendo o problema de dados inconsistentes e evitando soluções que implementam triggers, como seria feito no Postgres.

- Penso que dollar quoting não oferece nada que não se possa fazer no Oracle com double e single quotes mais bind variables. O Oracle 11g incluiu a package DBMS_ASSERT que automatiza a validação de strings contra o dicionário de dados para usar em SQL dinâmico.

Em resumo: sim, o RMAN é poderoso e importante, mas… não é algo sem o qual é impossível de se viver. Sim, eu uso RMAN, mas não sempre.

Dei mais uma lida lá (vou lendo aos poucos, o trampo ta consumindo muito do meu tempo!!!). Particularmente estava lendo os seus comentários sobre o RMAN, além do backup incremental, acho dificil você conviver sem um backup a nível de blocos como o RMAN te oferece, você ter um único bloco corrompido e ser salvo pelo RMAN sem ter que restaurar nada além daquele bloco desconheço isso no Postgres. O rman também trabalha em formatos acessíveis fora dele, você não precisa necessáriamente trabalhar com backupsets. O rman permite que você faça clonagem do banco em poucos segundos, permite que você faça restauração parciais, construa nós standby, permite que você não faça backup de espaço alocados e não utilizados, paralelismo no backup. Suporte a pipe para interação no banco enquanto realiza backup e finalmenteo conceito de change block tracking e a de duplicação.

Sem falar que os principais vendors de backups como ITSM, Net Backup, etc possuem suporte nativo ao Oracle. Sei que alguns tem para DB2 e para SQL Server, mas NENHUM tem para Mysql e Postgres…

O postgres consegue bater ou chegar perto?

Estou elaborando resposta para cada um dos itens que vocês contestaram, acho que vai ser uma discussão interessante.

Atenciosamente,
Caio Spadafora.

Muito boa sua explicação, só acresentaria que o Oracle existe uma conectividade direta para outros bancos de dados mais simples e robusta chamada Oracle Heterogeneous Services. Aqui na Embasa temos tres bancos de dados DB2 (mainframe), Oracle e PostgreSQL e estou implementando uma replicação dos dados corporativos que estao no DB2 para que o ORACLE seja a ponte de informações para o DATAWERE HOUSE (que esta no oracle) e tambem dos sistemas que precisam dos dados corporativos no PostgreSQL e vi que esta solução é mais simples e tem uma performance boa do que o DBLINK e o DBI-LINK.

Abraços

Também, poderiamos colocar a questão de consultas hierárquicas, utilizadas quando temos uma tabela Auto-Relacionada. O Oracle possui algumas cláusulas(CONNECT BY, START WITH PRIOR) que facilitam este processo. Já o Postgres devemos implementar uma função recursiva ou procurar alguma biblioteca de terceiros que tenha alguma solução semelhante.

Flw!

Trabalho com PLs nos dois lados..
Gosto de ambas, mas falando serio..
SOU BEM MAIS AS FUNCIONALIDADES DO PgSQL.

O Oracle não acho tão flexivel. E isso me atrapalha muito.
Tomara que melhorem MESMO nas proximas versoes.

Viva a PgSQL
=)

Muito bom esse teu espaço, hein!

Eis uma lista de features do Oracle que o PostgreSQL não possui, em ordem de prioridade:

1. Tablespace UNDO: considero a “galinha dos ovos de ouro” da Oracle. Nenhum outro SGBD consegue minimizar tanto a contenção do servidor!

2. Backup Diferencial: backup físico no PostgreSQL só temos FULL e transacional. Não existe esse meio termo…

3. Datafiles Freezing: o nosso pg_start_backup() bloqueia o cluster inteiro. No Oracle podemos fazer isso para um determinado tablespace apenas, reduzindo a quantidade de LOGs de transação criados nesse período.

4. Particionamento: infelizmente ainda não temos uma solução out-of-box para particionamento de tabelas. Utilizar aquele artifício de herança é de lascar…

5. Visões materializadas: como seria bom se tivesse isso no core do PostgreSQL…

6. COUNT(): essa função de agregação que os programadores têm verdadeira tara pode simplesmente tornar-se um pesadelo para o DBA! Não sei como o Oracle trata essa questão, mas no PostgreSQL é um calcanhar de Aquiles por provocar full scans…

7. Transações em PLs: pra quem faz uso excessivo de processamentos em funções, isso faz uma tremenda falta, provocando a secção de uma procedure em diversas no PostgreSQL.

8. Funções analíticas: às vezes dá pra “se virar”, construindo-as em PL/pgSQL, mas não é a mesma coisa em questões de desempenho…

9. Cluster tables: diferentemente de outros SGBDs, o Oracle consegue armazenar fisicamente juntas estruturas relacionadas, como tabelas de Pedidos e Linhas de Pedidos.

10. Backup dump inconsistente: no PostgreSQL o pg_dump sempre faz as cópias com consistência. Eliminando isso talvez dê uma acelerada no processo.

11. Raw devices: antigamente achava que não suportá-los era uma falta do PostgreSQL. Acompanhando a pg_hackers vi que o Oracle a suporta por uma questão histórica. Reinventar um sistema de arquivos não é tarefa para o time do PostgreSQL.

12. Nested tables: não conheço muito disso o suficiente para comentar.

13. Sinônimos: não existe no PostgreSQL simplesmente porque é desnecessário nele! A variável de sessão search_path é muito mais interessante, na minha opinião.

Abraço,

Hjort