16 características do Oracle que fazem falta no PostgreSQL

Bom, depois de escrever sobre algumas vantagens do PostgreSQL em relação ao Oracle, chegou a hora de fazer o inverso. Eis aqui algumas características do Oracle que eu realmente sinto falta no PostgreSQL.

  • Triggers de sistema. O Oracle possui a capacidade de disparar gatilhos quando você inicia o SGDB, quando um usuário se conecta, quando realiza uma operação de DDL, etc. Isso ajuda muito para quem quer realizar auditorias e construir alguns esquemas especiais de segurança. Além disso, o Oracle possui o AUDIT que que é um comando que utiliza uma estrutura pronta para auditar diferentes eventos;
  • O PostgreSQL também tem ferramentas para gerar logs, mas o Oracle realiza isso com maior nível de controle, permitindo especificar uma sessão específica. Isto ajuda muito para monitorar uma ação específica dentro de um ambiente de produção.
  • O Oracle permite de indicar um tablespace separado para o Tablespace TEMP e UNDO. Isto permite um ajuste de desempenho melhor, particularmente colocando o tablespace TEMP em outro disco em aplicações de BI que fazem consultas enormes. É claro que você consegue fazer isto no PostgreSQL utilizando links simbólicos, mas esta não é a forma mais elegante de se fazer isto. A versão 8.3 do PostgreSQL já deve trazer avanços neste sentido.
  • Fine -Grained Access, é uma ferramenta do Oracle que permite o acesso a determinadas linhas de uma tebela de acordo com o perfil do usuário conectado. Este é um recurso interessante que em aplicações corporativas podem ajudar um bocado.
  • Maior flexibilidade na definição dos arquivos de log de transação. No Oracle é possível determinar o tamanho e o local de cada log, além de fazer um espelhamento se você desejar. O PostgreSQL permite alterar o tamanho dos arquivos de log alterando um parâmetro no código fonte e também é possível criar links simbólicos para alterar a posição dos arquivos de log. No entanto, acho que o Oracle tem uma solução mais robusta neste ponto.
  • O Oracle tem a possibilidade de criar tablespaces com diferentes tamanhos de bloco e buffers específicos para cada tamanho de bloco. Num ambiente que mistura características de OLTP com BI, isto pode ser interessante. É claro que oideal seria separar os dois ambientes em servidores distintos. No entanto esta opção confere ao Oracle uma flexibilidade adicional no ajuste de performance e uso do disco.
  • SQLLoader é uma ferramenta para importação de grandes volumes de dados em arquivos texto em diversos formatos. E uma ferramenta realmente robusta e flexível que pode lhe ajudar a fazer ETL, migrar dados de plataformas distintas, etc.
  • O Oracle permite a paralelização de operações pesadas, incluindo backups lógicos, importações via SQLLoader, consultas longas, etc. No PostgreSQL, você tem o PGPool II que permite a paralelização de consultas pesadas, mas não tem ferramentas para outras situações. Você também pode disparar duas operações de backup lógico em separado definindo partes diferentes do banco de dados para a operação. No entanto, crieio que a opção de paralelização seja uma alternativa interessante.
  • O RAC (Real Aplication Cluster) é uma solução conhecida de cluster de banco de dados no Oracle. O RAC é uma solução que permite escalar o Oracle horizontalmente além de prover uma considerável tolerância a falhas. O PostgreSQL tem a capacidade de escalar verticalmente melhor que o Oracle, mas não tem ainda uma solução para escalar horizontalmente, nem uma solução para tolerância a falhas que seja síncrona, apesar de em Linux existirem soluções para isto. Existe um projeto chamado PGCluster II que promete fazer uma implementação semelhante ao RAC no PostgreSQL.
  • As ferramentas de monitoramento da Oracle são realmente úteis. A partir do Oracle 10g o “Database Control” tem facilidades realmente interessantes e acredito que a versão 11g tenha melhorado mais ainda isso. Existe um projeto chamado Cedrus que promete cobrir boa parte deste vácuo no PostgreSQL. No entanto, já existem ferramentas como o Munin, que fazem um bom monitoramento do servidor e possui algumas extensões para o Oracle, PostgreSQL e MySQL, além de ser simples criar novas extensões.
  • Ajuste automático de memória. O Oracle possui alguns parâmetros de inicialização se ajustam limites de memória para o Oracle e deixa ele distribuir este espaço entre as diversas áreas internas. Isto realmente pode simplificar muito o trabalho do DBA. Já ouvi falar que o pessoal da SUN tem interesse em investir em mecanismos deste tipo no PostgreSQL, mas isto ainda deverá levar alguns anos para se concretizar.
  • Os índices do tipo bitmap ajudam muito em colunas de baixa cardinalidade e poucas gravações. O PostgreSQL tinha programado para implementar esta funcionalidade na versão 8.3 mas adiou para a versão 8.4. No entanto os índices bitmap são utilizados na memória (mas não em disco) no PostgreSQL em durante uma busca.
  • O Particionamento de tabelas do Oracle também tem algumas vantagens sobre o particionamento do PostgreSQL como o particionamento por hash e outras funcionalidades que ajudam a dar manutenção em tabelas particionadas.
  • Controle de transações dentro de um bloco PL/SQL. Isto é algo que me faz falta no PostgreSQL quando você precisa de funções mais complexas. No PostgreSQL todo o bloco PL roda dentro de uma única transação, enquanto do Oracle você pode declarar o begin, commit, rollback e savepoint dentro do PL/SQL.
  • Visões materializadas, são coisas possíveis de serem feitas utilizando-se gatilhos e funções no PostgreSQL, mas é bem mais fácil quando você já tem uma estrutura sintática pronta para isso como no Oracle.
  • O Jobs Scheduler é ferramentas do Oracle que permite o disparo de ações específicas através do agendamento em horário específico, se repetindo ou não em intervalos programados. Muitas pessoas resolvem esta ausência utilizando o CRON do Linux, mas o Job Scheduler tem uma série de funcionalidades interessantes, além de permitir tratar tudo via SQL.

É claro que o Oracle tem a mania de abocanhar o mundo e oferece uma miríade de funcionalidades, algumas exóticas e certamente algumas que eu não conheço. Se você sentiu falta de algum item, por favor deixe a sugestão nos comentários. Muito do que está aqui acaba sendo importante para quem pretende migrar de Oracle para PostgreSQL e não sabe se vai encontrar as funcionalidades que espera.

38 comentários sobre “16 características do Oracle que fazem falta no PostgreSQL

  1. É Celso, é verdade. Acredito que quando penso em ferramentas de monitoramento, estou englobando isso. Mas talvez eu não tenha sido muito preciso, uma vez que as ferramentas analíticas podem existir sem as ferramentas de monitoramento, mas não o contrário.
    Valeu pela contribuição.
    Caro Ribamar, preciso parar de escrever com pressa (é que a discussão na lista do PostgreSQL está tão interessante que eu queria aproveitar o momento). Mas vou ver se tomo vergonha na cara e começo pelo menos a usar um corretor ortográfico. Obrigado pelos toques!
    Ah… sim, não deixem de acompanhar a discussão na lista do PostgreSQL que está muito bacana.

    Curtir

  2. Flashback quey.
    Com certeza é um recurso que deixa qualquer um louco :

    Ex.: select codproduto,qtdestoque from estoque as of timestamp trunc (sysdate + (8 / 24))

    Como estava a tabela de estoque hoje às 8:00hs da manhã.

    Esse recurso já salvou minha vida, uma vez, achei que estava logado na base de desenvolvimento, porém era a base de produção, zerei todo o estoque…
    Resolvi tão rápido que o pessoal nem percebeu, consultei como estava a base antes de ter dado o comando e fiz um “ctrl+z”. Se fosse outro banco teria que voltar backup, e provavelmente seria demitido.

    Curtir

  3. Índices bitmap tá sendo um parto heim? Nunca precisei de transações dentro de procedures, mas penso serem bem úteis. Uma coisa que é um pouco chatinha no PostgreSQL é o fato de sempre usar o collate do initdb para ordenações 😦 Mas um dia nós chegamos lá!

    Curtir

  4. Olá, eu não conheço quase nada no PostgreSQL, mas conheço um pouco de Oracle. Ai vai a pergunta. O PostgreSQL possui as features de Flashback (Database, Table, Transaction e Query)? Esse é uma dos recursos que eu mais gosto no Oracle.

    Curtir

  5. O que mais sinto falta são os monitoradores mesmo. No DB2 há um ‘caminhão’ de coisas que dá para monitorar na base toda ou apenas numa conexão.

    Aqui vai uma dica, para quem precisa monitorar o que um determinado usuário está mandando para o banco no ODBC, por exemplo:

    set log_statement="all"

    Muita gente acha que esse parâmetro pode ser definido apenas no postgresql.conf, mas ele pode também ser definido por conexão.
    Depois é só setar o log_line_prefix com o que se quer (por ex.: “”) e capturar nos logs tudo o que passa pelo server apenas daquela conexão.

    Abraço.

    Curtir

  6. Opa,
    Acho que faltou ai a parte de caracteres, no Oracle a parte de charset é bem complexa.
    As possibilidades para definicões de língua, território e parâmetros afins fazem muita falta quando várias pessoas (com línguas diferentes) acessam o banco ajudam muito.
    Faltou citar o RMAN, que é uma mão na roda pra backup. Claro que sempre com o modo ARCHIVELOG. Um RMAN no PostgreSQL seria muito bom, já teria me facilitado a vida algumas vezes.
    Outra coisa seriam os parâmetros dinâmicos, no Oracle muita coisa é dinâmica e você pode alterar em tempo real. Shared servers (sem haver com o RAC) também fazem uma falta no PostgreSQL.
    Profiles de usuários também ajudam. Mas nessa parte acho que o PostgreSQL dá uma lavada. O vínculo de esquema e usuário no Oracle é muito forte (eles tem o mesmo nome), no caso do PostgreSQL são separados (e nada que um search_path não resolva).
    Até mais.

    Curtir

  7. O PostgreSQL tem a maioria das opções de localização que o Oracle, basta ver isso na documentação. O PostgreSQL tem o suporte a UTF-8 já há um bom tempo também. E tem algo que eu realmente não gosto no Oracle é ter que usar o NVARCHAR ou o NCHAR. Realmente a Oracle complica muito isso. Eu tenho a impressão que a Oracle criou isso para suprir deficiências no tratamento com caracteres multibyte.

    O RMAN realmente é algo interessante, mas eu acho que só vale a pena mesmo se você precisa de backp incremental. Caso contrário, você pode se virar muito bem com seus próprios scripts. A razão de eu prefirir os scripts é que o formato do backup gerado pelo rman só pode ser utilizado por ele. Uma vez utilizando o RMAN, você está preso a ele. Eu realmente prefiro ter mais controle da situação. Este é um dos motivos para eu não ter citado o ASM. Particularmente o pessoal do PostgreSQL optou por não desenvolver o armazenamento em RAW Devices. O motivo é mais ou menos o mesmo de evitar o RMAN, além da filosofia de que o PostgreSQL desenvolve um SGDB e não um SO. Para desenvolver SO, já exite muita gente fazendo um excelente trabalho.

    Os parâmetros dinâmicos o PostgreSQL também suporta, por sessão, por transação, por banco de dados ou por usuário. Com isso, a parte de perfis é contornada com tranquilidade. O fato de poder setar parâmetros por usuário ou ROLE, atende a boa parte dos recursos dos perfis de forma bastante simples e elegante. Mas é claro que isto poderia avançar um pouco mais.

    Curtir

  8. Opa,
    Concordo com muita coisa que você falou. A parte de ROLES do PostgreSQL dá um show na da Oracle. Quanto as partes dos parâmetros, acho que não me expliquei direito, estava falando da gerência da instância. No Oracle você tem mais controle, mais parâmetros dinâmicos estão disponíveis do que no PostgreSQL. Ai também tem um exagero, são parâmetros demais no Oracle 🙂
    Quanto ao RMAN, você captou a idéia, backup incremental. Claro que os backupsets são uma mão na roda quanto ao uso de disco, mas como você falou. Só o RMAN entende. E outra coisa incremental só com o bendito ARCHIVELOG. Sim o ASM é algo estranho, confuso demais. Por exemplo, se você tem problema em um controlfile e quer copiar um sobre o outro, em S.O. isso é muito fácil.. mas no ASM? Via SQL… acho que não dá muito certo. E se o ASM der problema?
    Já com os caracteres, o unicode é um santo remédio. O que eu quis falar é que com o Oracle você pode mudar muitos mais parâmetros do que no PostgreSQL, você tem mais controle (pode até criar um charset prórpio). Sorts, index’s, territórios e outros. Sim, também concordo que N*** da vida são bem chatos
    E concordo com você, quem faz banco deve se preocupar com o banco de dados, e não com coisas/fazer coisas do S.O.

    Curtir

  9. A questão do SQLLoader da Oracle não é simplesmente a velocidade, mas sim flexibilidade. Com o Loader você pode importar arquivos com colunas de tamanho fixo sem separadores, fazer conversão de tipos de dados on the fly e o mais importante, gerar um arquivo com as linhas que deram problema. O Loader é uma ferramenta muito poderosa com toneladas de opções. Uma coisa interessante para quem está preocupado com desempenho é que você pode separar os dados de entrada em vários arquivos e paralelizar (em disco e processador) a importação. São algumas coisas que o PostgreSQL ainda não faz. O Bizgres Loader já tem boa parte destas características e espero vê-las incorporadas diretamente no PostgreSQL em breve.

    Curtir

  10. Grande Telles!

    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

    Curtir

  11. Ola amigos..

    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
    =)

    Curtir

  12. Pingback: SAVEPOINT » O que aprendi com o blog

  13. Olá,

    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!

    Curtir

  14. Parabéns a todos,
    tudo que está escrito fica dentro das diferenças mesmo.
    Mas como DBA o que eu realmente sinto falta no PostgreSQL e tenho no Oracle
    para pequenos e médios são o RMAN e o RAC.

    Abraços

    Curtir

  15. Caro Telles,

    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.

    Curtir

  16. Telles,

    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.

    Curtir

    • Caio, é como eu disse antes: o RMAN é uma ferramenta muito interessante. É claro que ela pode fazer backups em “formatos acessíveis”, mas se você fizer isso, não pode utilizar 90% dos recursos que você mencionou depois. Dá para viver sem o RMAN sim. Tem um montão de gente que usa Oracle e não usa RMAN. Se você estiver utilizando ASM, aí sim não existe escapatória. É claro que você não é obrigado a utilizar o ASM. Mas se você utiliza RAC com licença Standard você é obrigado a utilizar o ASM. Como você vê… a Oracle vai lhe cercando…

      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.

      Curtir

  17. Do ponto de vista de desenvolvedor eu acho que o Oracle leva uma vantagem grande, tanto pela questão do controle de transações em PL/SQL que não há em PL do Postgres como nas várias possibilidades que a linguagem oferece.

    – 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.

    Curtir

    • Ok FSITJA. O PostgreSQL não tem suporte a COMMIT e ROLLBACK dentro de um bloco PL. Concordo com você.

      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? 😛

      Curtir

  18. Olá Fabio,

    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;

    8) 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

    Curtir

    • Obrigado pela contribuição Rodrigo. Realmente o Oracle possui funcionalidades interessantes, não é mesmo? Mas você exagerou na sua lista, talvez por não conhecer algumas funcionalidade do PostgreSQL:

      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.
      8) 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.

      Curtir

  19. Olá Telles,

    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

    Curtir

  20. Adorei os artigos sobre as características que tem no PostgreSQL e faltam no ORACLE e o contrário.
    Mas acredito que já esteja na hora de criar novos artigos pra poder estar atualizando informações.
    Seria muito bom, iria reavivar uma discussão sobre o assunto, muito interessante por sinal.
    Abraços

    Curtir

  21. Pingback: O que aprendi com o blog | Savepoint

  22. Pingback: Oracle X PostgreSQL - Parte I: Semelhanças - Savepoint

  23. Pingback: Prova do Dataprev - Questão de banco de dados e BI comentadas.

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s