Colega, não trabalho especificamente com pg, mas sem sombra de dúvida testes, testes e análise e mais análises do SEU aplicativo é que vão embasar a sua decisão e o seu relatório - óbvio, nós sabemos que se o chefe quiser impor ele impõe mesmo e azar, mas como especilista em banco o seu dever é produzir um relatório ** técnico ** apontando as diffs e recomendando, se o chefe não ligar pro seu relat e fazer de acordo com a cabeça dele, pelo menos a sua obrigação vc fez, é isso.... Imho a primeira área de diferença grande que vc vai ter que analisar ao se comparar entre banco não_oracle e e Oracle são as features : evidente que vc consegue escrever um código seu fazendo no seu banco que não tem o mesmo efeito que uma built-in do banco, MAS isso custa tempo e $$ pra desenvolver, e quase NUNCA fica performático, já que a built-in está lá enfronhada no kernel do banco, usando & abusando de hooks internos, feita em C ainda por cima , coisa que o nosso código dificilmente consegue ser... Assim, sugiro pra iniciar que vc consulte o manual Oracle de DW , sei que várias das features lá citadas (em especial algumas bitmap indexes, particionamento - particionamento físico, real, em disco, e não via constraints -, funções analíticas, e alguns mais) não existem ou existem parcialmente nos outros bancos : então se vc usa essas feats no seu sistema, já tá comprovado que vai ter problemas, é simples em bancos-teste que vc crie numa máquina sua vc criar um exemplo usando as features no Oracle, um não as usando no pg e relatar pro seu chefe a diferença... ESSE é o ponto, se vc usa ou pode usar o recurso x presente no Oracle e não-presente no banco y, COM proveito, obtendo RETORNO mensurável, esse é um indicador apontando para o Oracle, já se o seu sistema é um genérico pelaí que mal e mal usa as features básicas, E não há a menor pretensão de usar, essa situação aponta para a possibilidade de troca. Entre essas, aliás, funções analíticas são mesmo um ** mundo ** de diferença, no Workshop eu dei uns exemplos simples, mas é em rotinas mais complexas que se pode apreciar essa característica Oracle... Afora essas de dw específicas, algumas features gerais importantes (de uso tanto em dw como em oltp) presentes no 10g e no 11g , várias que sei que não presentes ou estão incompletas em alguns outros bancos estão em http://www.oracle.com/technology/pub/articles/10gdba/index.html e http://www.oracle.com/technology/pub/articles/oracle-database-11g-top-features/index.html , veja lá , se vc as usa ou pode vir a usar em breve, são um argumento forte a favor do Oracle, em especial o Flashback, o ASSM, o Auditing nativo... A segunda área é a instrumentação do banco : necessariamente no dia-a-dia na solução de problemas constantemente vc VAI ter que checar performance, debugar, consultar stratus de processamento/nível de uso do banco, validar o porque de um plano de execução, e o bd Oracle tem *** várias *** opções built-in pra isso, muitas e diversas tools pra te ajudar, desde a tradicional wait interface até o ASH, o ADDR, as views melhoradas de SQL, as de histórico (DBA_HIST_xx) , os traces 10046 e 10053 (este último inestimável para vc analisar o comportamento do CBO)... Vc tem que montar um relatório mostrando que essas opções todas existem para te ajudar no bd Oracle, não necessariamente existem com o mesmo escopo no pg, o custo de vc não ter ferramental a mais tem custo também... Se ao analisar a situação atual do pg (que é o seu banco não-Oracle alvo no caso) vc ver que essas tools de análise não estão tão avançadas, bote isso no seu relatório, expresse que isso pode ser um diferencial negativo, que PODE levar a tempos de resolução maiores, análises mais difíceis... Óbvio, provavelmente o chefe vai pouco se lixar pra essa parte de infra e mandar vc se virar com o que tenha, mas registre isso. Um terceiro ponto é a estabilidade, tanto a atual quanto a prevista : vc deve por em consideração que fazem mais de vinte anos que o bd Oracle existe, necessariamente deve ser menor a quantidade de bugs show-stoppers - não que não existam, mas o histórico no caso é favorável. O ponto final indicando pro-Oracle é a comunidade : devido à muito maior participação no mercado, liderando normalmente o mercado, e um pouco também ao tempo de existência, vc tem literalmente dezenas de fontes de referência de alta qualidade sobre Oracle, grupos de usuários, livros excelentes como os do Tom Kyte, do Jonathan Lewis , etc, nem sempre vc tem isso na mesma quantidade e qualidade para outros bancos com menores parcelas de mercado. Num apanhado geral, acho que esses são os pontos que vc deve analisar e citar no seu relatório. Mais uma vez repito, é comum o chefe não por em consideração custos escondidos decorrentes de falta de built-ins , de tools de performance, de referência da comunidade, mas liste lá. []s Chiappa ====================================================================== Palestrante ENPO.BR - acesse http://www.enpo- br.org/ Instrutor Workshops ENPO/TWS - acesse http://www.twstecnologia.com.br/ Agora Blogando em www.ora600.com.br - confira as novidades ! ====================================================================== "Sempre imaginamos que o trabalho do outro é mais fácil que o nosso. Quanto melhor ele faz, mais fácil parece." Eden Phillpotts
--- Em oracle_br@yahoogrupos.com.br, "Bruno Fantin" <bruno_fan...@...> escreveu > > Senhores. > > Aqui na firma estão pensando em mudar do Oracle para o PostgreSQL. Lógico que eu não gostei muito da idéia. > > Queria saber se vocês tem artigos, comparações ou algo do tipo entre os dois para servir de defesa para o Oracle. > > Grato. > > Bruno Fantin. > > [As partes desta mensagem que não continham texto foram removidas] >
