Base de dados java com oracle, a logica fica no oracle ( base de dados orientado a objectos)

sulito:

pessoal eu quero debater o seguinte , o oracle a partir do 8 ja suporta orientação a objectos, mas quase não se usa , usa-se mais o velho e bom modelo relacional,

alguem sabe da vantagens e desvantagens de usar modelo orientado a objectos no oracle ?
orientação a objectos vs modelo relacional
eu estive estudando o modelo orientado a objectos do oracle para criar tabelas e meter toda a lógica de negocio no oracle e achei vantajoso, mas não entendi porque
que pouca gente usa, porque usando o modelo orientado a objecto dentro do oracle em vez do modelo relacional, temos todas (quase todas) as vantagens do
modelo orientado a objecto ( polimorfismo, herança, etc )
porque usando o modelo orientado a objecto nos nossos sistema no lado java acho que sera necessario ter apenas os dao, sem ser preciso usar mais classes
onde ficara a logica do negocio

Bom… eu trabalhei com oracle durante algum tempo, porém muitas pessoas não tem conhecimento de orientação a objetos em oracle, assim como também, existem muitas pessoas que não gostam de oracle, etc.
Eu particularmente, nas empresas em que trabalhei com oracle, eles não utilizavam pq , apesar de estarem migrando o sistema para java, o sistema é todo feito com Oracle Forms e Reports 6i, o qual não suporta Types (Forma de utilizar orientação a objetos no oracle), se não me engano, types orientados a objetos surgiu a partir da versão 9i.

em uma discussão que estava rolando no fórum de oracle, glufke, fiz um exemplo com orientação a objetos em oracle.
http://glufke.net/oracle/viewtopic.php?p=14360#14360

Eu acho bem interessante e útil os types, porém, alguns colegas meus, certificados da oracle inclusive, falaram que até a versão 10g, ou 9i, não me recordo, os types, e tabelas baseadas em types eram mais lentas que as tabelas normais. Talvez isso fosse um dos motivos para não usarem.

e sem dúvida, código executado no prórpio SGBD é mais rápido que executado na aplicação! Na empresa em que eu trabalhava com oracle, toda a lógica de negócios estava em packages no banco ( PL/SQL rocks ).

[]'s

Mas caso seu sistema seja distribuido para varios clientes, você obriga todos a terem o Oracle, se as regras de negócio ficarem na Oracle.
E o Oracle é bem caro.
Muito bom por sinal.

Mas você acaba limitando a sua aplicação a ser utilizada apenas nele, talvez por isso não seja muito utilizada a O.O em banco de dados. O Postgress também tem O.O e poucos utilizam.

jhonatandarosa:

Bom… eu trabalhei com oracle durante algum tempo, porém muitas pessoas não tem conhecimento de orientação a objetos em oracle, assim como também, existem muitas pessoas que não gostam de oracle, etc.
Eu particularmente, nas empresas em que trabalhei com oracle, eles não utilizavam pq , apesar de estarem migrando o sistema para java, o sistema é todo feito com Oracle Forms e Reports 6i, o qual não suporta Types (Forma de utilizar orientação a objetos no oracle), se não me engano, types orientados a objetos surgiu a partir da versão 9i.

em uma discussão que estava rolando no fórum de oracle, glufke, fiz um exemplo com orientação a objetos em oracle.
http://glufke.net/oracle/viewtopic.php?p=14360#14360

Eu acho bem interessante e útil os types, porém, alguns colegas meus, certificados da oracle inclusive, falaram que até a versão 10g, ou 9i, não me recordo, os types, e tabelas baseadas em types eram mais lentas que as tabelas normais. Talvez isso fosse um dos motivos para não usarem.

e sem dúvida, código executado no prórpio SGBD é mais rápido que executado na aplicação! Na empresa em que eu trabalhava com oracle, toda a lógica de negócios estava em packages no banco ( PL/SQL rocks ).

[]'s

A respeito do exemplo que está no seu link isso é PL/SQL?
Se for, vc tem alguma referência bibliográfica sobre o assunto?

sulito:

sem esquecer de dizer que num sistema com muitos dados se a logica de negocio estiver dentro da base de dados (oracle), ficara mais rapido porque as operações
feitas dentro da base de dados são sempre mais rapida daquela feitas pelo java enviando para a base de dados.

Simples, a suposta performance obtida com essa solução não compensa os custos. Fora o risco envolvido ao se adotar uma plataforma paga e proprietária. O que vc faria se a Oracle de uma hora pra outra elevasse o valor das lincensas para valores astronomicos?

Migrar os dados para qualquer outro tipo de armazenamento é muito fácil hoje em dia, o mesmo não pode ser dito dos algoritmos e regras de negócio.

Bom, longe de mim querer dizer o que é melhor ou pior.

No entanto, dizer que a colocar a lógica dentro do banco de dados torna o aplicativo mais rápido é relativo.

Se o seu servidor de Banco de Dados estiver “sobrando” o suficiente, poderia até colocar o banco de dados e servidor de aplicação na mesma máquina para compensar o overhead de acesso a rede. (acho que é aí que dizem que tem um bom ganho de performance).

Se o servidor já está “no talo”, com o código rodando dentro dele e o aumento de carga, vc vai acabar tendo que
A - comprar um servidor mais forte, o torna possĩvel a solução mencionada anteriormente.

B - clusterizar o servidor. Nesse caso, já que vc vai ter o overhead da rede de qualquer modo, porque nao separar dados de inteligência?

Dadas essas observacoes, acho que colocando a inteligencia dentro do banco, se tiver ganho de performance, nao deve ser significativo.

Além do mais, existem várias técnicas (cache, por exemplo), para que vc possa otimizar a perfomance do servidor de aplicacao.

Uma das defesas da galera separar a inteligencia do banco de dados é poder trocar de BD. Concordo com isso, mas até hoje nao vi ninguem trocar o BD de uma aplicacao em producao. Pra mim, a grande vantagem é a separacao de responsabilidades. O BD passa a ser repositorio de dados que ele sempre devia ser e a inteligencia fica em uma aplicacao.

O modelo de inteligencia no banco de dados fazia muito sentido na epoca da arquitetura client/server. Vários aplicativos clientes para os mesmos dados. Com a logica no servidor, vc evitava ter que repeti-la nos aplicativos clientes varias vezes.

Abs

Acho que o pessoal tem toda a razão, se usarmos o modelo orientado a objectos ai a nossa aplicação fica apenas limitada em oracle , e na maioria dos outros SGBD (mysql, postgre, etc…) podera não funcionar porque mesmo que suportar modelo orientado a objectos a implementação ( codificação do modelo orientado a objectos e a forma de usar) com certeza não sera a mesma.
mas o que eu penso é o seguinte sendo a oracle o que é hoje ( biggest enterprise), com certeza eles tiveram um grande motivo para por
o modelo orientado a objectos dentro da base de dados e com certeza tera grandes vantagens sera???

Acho que o motivo da Oracle fazer isso é bem simples, e não tem muito a ver com performance. Quanto mais recursos você utilizar “dentro do banco”, ou seja, recursos do SGBD, mais preso você fica ao vendedor do SGBD. Logo, para a Oracle, se eles colocarem tal recurso e ele “pegar”, é ótimo para eles, pois eles ganham mais mercado.

Ainda mais no cenário atual, em que bancos de dados livres como Postgres e MySQL conseguem atender muito bem a maior parte da demanda. O Oracle precisa de um diferencial.

moacirjava:

jhonatandarosa:

Bom… eu trabalhei com oracle durante algum tempo, porém muitas pessoas não tem conhecimento de orientação a objetos em oracle, assim como também, existem muitas pessoas que não gostam de oracle, etc.
Eu particularmente, nas empresas em que trabalhei com oracle, eles não utilizavam pq , apesar de estarem migrando o sistema para java, o sistema é todo feito com Oracle Forms e Reports 6i, o qual não suporta Types (Forma de utilizar orientação a objetos no oracle), se não me engano, types orientados a objetos surgiu a partir da versão 9i.

em uma discussão que estava rolando no fórum de oracle, glufke, fiz um exemplo com orientação a objetos em oracle.
http://glufke.net/oracle/viewtopic.php?p=14360#14360

Eu acho bem interessante e útil os types, porém, alguns colegas meus, certificados da oracle inclusive, falaram que até a versão 10g, ou 9i, não me recordo, os types, e tabelas baseadas em types eram mais lentas que as tabelas normais. Talvez isso fosse um dos motivos para não usarem.

e sem dúvida, código executado no prórpio SGBD é mais rápido que executado na aplicação! Na empresa em que eu trabalhava com oracle, toda a lógica de negócios estava em packages no banco ( PL/SQL rocks ).

[]'s

A respeito do exemplo que está no seu link isso é PL/SQL?
Se for, vc tem alguma referência bibliográfica sobre o assunto?

sim… isso é PL/SQL… me manda uma mensagem privada lembrando de te mandar, vou procurar o material que eu tenho! =D

andreban:

Acho que o motivo da Oracle fazer isso é bem simples, e não tem muito a ver com performance. Quanto mais recursos você utilizar “dentro do banco”, ou seja, recursos do SGBD, mais preso você fica ao vendedor do SGBD. Logo, para a Oracle, se eles colocarem tal recurso e ele “pegar”, é ótimo para eles, pois eles ganham mais mercado.

Ainda mais no cenário atual, em que bancos de dados livres como Postgres e MySQL conseguem atender muito bem a maior parte da demanda. O Oracle precisa de um diferencial.

bom, eu trabalhei com oracle por um bom tempo, inclusive SGBD Oracle e aplicação em Oracle Forms & Reports, e também SGBD Oracle e aplicação em Java (Este por menos tempo).

fiz testes de performance com estas tecnologias, e posso afirmar, com base nos meus testes, que tem-se um ganho de performance, utilizando a PL/SQL para fazer a lógica de negócio, e acredito que o motivo desse melhoria de performance, seja o acesso direto (sem necessidade de fazer conexões) ao banco.
o próprio SGBD faz algumas otimizações com relação ao código feito em PL/SQL, dentre outras coisas.

[]'s