Olá
Saiba que para muitos o Oracle não passa de um sistema gerenciador de base de dados ideal para aplicações de porte limitado em plataformas baixas. Saiba que muito grandes bancos e entidades que precisam realmente de poder usam coisas do tipo de teradata
E pior. Algumas empresas que eu sei precisaram migrar de outras bases que não deram conta do recado.
[]s
Luca
opinião pessoal :
tudo depende do cliente e do que ele esteja disposto a gastar com a solução.Eu,particularmente,gosto muito do oracle.Conheço ele um pouco
e já fiz coisas legais com ele,porem nós não podemos nos empolgar com nossos anseios e complicar as coisas.Como eu disse cada caso é um caso
no final das contas quem deve se dar bem é o cliente que está nos pagando,pois com o sucesso do cliente o nosso sucesso fica evidente.
o que nós sabemos é que não se deve ficar dependente de um fornecedor, incluindo um fornecedor de banco de dados 
o q vc qer dizer com dependente d fornecedor d banco d dados??
Ficar dependente eh aquela sensacao esquisita que a gente tem quando, por exemplo, voce nao tem grana pra comprar o BolaDeCristal 11h mas o fornecedor esta pressionando a migracao (mesmo que o seu dez gramas funcione a contento).
Independencia de fornecedor eh uma Coisa Boa™. Se eu deixasse minha esposa comprar Omo todos os meses tava ralado. 
Marcio Kuchma
digamos que vc baseie toda a sua aplicação em stored procedures e triggers, deixando boa parte da lógica de negócio para o Banco de Dados
aí, no meio do desenvolvimento, seu cliente resolve trocar de banco de dados, ou então vc mesmo verifique que é melhor usar um outro método de persistencia
aí vc ta ferrado, vai ter que refazer toda a parte de acesso a dados
Rubem, vc tera esse tipo de problema em qualquer situacao. Ate a linguagem de programacao pode mudar ( e costuma mudar mais facilmente que o banco de dados ).
Nao precisa basear toda a aplicacao em procedures, mas sim saber usar corretamente. Sendo visao fechada assim vc estara deixando de usar recursos otimos para muitos casos, escrevendo ( digo, reescrevendo ) codigo para o qual ja existe ferramentas que lidam com a situacao.
Em programacao vc esta sujeito a fazer refactoring de maneira constante, e isso inclue todas as partes envolvidas, seja banco, seja na linguagem de programacao que esta sendo utilizada. Voce soh tem a perder com essa mania de fazer sistemas genericos.
Rafael
o cliente resolver trocar d banco??? desde quando o cliente q decide qual banco usar??? qem tah fazendo o sistema e sabe qual a solucao melhor eh vc e nao o cliente, q eh leigo…o cliente deve t dizer oq o sistema deve fazer e naum como desenvolvê-lo
mudar o método d persistencia no meio do projeto??? mas num eh feito um planejamento/estudo antes d comeca a desenvolver, pra naum acontecer d ficar mudando toda hora d requisitos e especificacoes???
alguem discorda da minha opiniao??? :?:
P.S.: quando eu disse q tava parecendo q vcs naum conheciam nada d BD eu tava qerendo dize q c deixar todas as regras d negocio na aplicacao eu estaria subestimando o SGBD
Eu discordo Lich King.
Clientes que usam bancos de dados pagos nunca vão aceitar que um fornecedor o obrigue a comprar um outro. Uma empresa que gastou 2-3 milhões de reais num servidor com Oracle/SQL Server/DB2/Teradata/outro DMS nunca vai aceitar ter que adquirir outra solução.
Hoje em dia desenvolver um produto que suporte não os 4-5 bancos mais populares é fechar portas antes mesmo de encontrá-las.
Existem clientes que nao sao leigos.
Existem ambientes em que seu sistema nao sera o pioneiro (primeiro a entrar em utilizacao), pois ja existe todo um ecossistema em pleno funcionamento.
Obviamente em ambos os casos o cliente tera diretrizes que deverao ser seguidas como parte dos requisitos.
Infelizmente o mundo nao eh tao simples.
Marcio Kuchma
[quote=Lich King]
o cliente resolver trocar d banco??? desde quando o cliente q decide qual banco usar??? [/quote]
Eh o cliente que paga o teu salario ;). Ele pode perfeitamente decidir qual banco usar, principalmente nos casos onde pagou uma consideravel forturna em hardware e licencas de uso.
Rafael