Sistema crítico - Sugestões?

Pessoal, a empresa onde eu trabalho possuí um sistema cujo as principais ações estão programadas em PL/SQL. Sou da equipe de Java e não participo desse projeto, mas agora eles estão querendo migrar uma rotina que representa 40% do sistema para Java e Hibernate. O sistema já está desenhado totalmente estruturado, com todas as tabelas já presentes, as quais terei que utilizar. O principal problema dessa rotina atualmente é o tempo que ela demora para ser executada pois envolve várias regras de negocio que são executadas.

Primeira pergunta: Vocês acham que acessandando estas tabelas ja prontas pelo Hibernate e mapea-las em objetos seria a melhor maneira? Ou seria melhor eu criar uma outra estrutura própria totalmente OO e depois de executar essa ação, alimentar essas tabelas do sistema legado?

Segunda pergunta: Vocês recomendam algum caminho que por experiencia de vocês eu deveria seguir ou pelo menos partir dessa linha?

Obrigado.

Aew… então na minha opinião mapear uma tabela (não orientada) não é o melhor caminho porque ai seus beans seriam baseados na tabela oque poderia prejudicar a OO.
O Hibernate é uma framework muito boa facilita muito a vida do programador mais ela mal utilizada pode causar problemas que deixam qualquer um louco.
Eu uso hibernate e aconselho !!!
Mais antes de uma lida sobre o mesmo porque o Hibernate é mais lento que JDBC demora um tempo significativamente maior esse ano mesmo deu uma procurada no google e vi um teste comparando um com o outro e em algumas coisas o hibernate quase dobrava o tempo de um jdbc normal…
É o que eu falei com o hibernate você tera ganho em varias coisas coloque as coisas no papel e ve se é isso mesmo que você esta querendo…

:smiley:

Valeu rdgms,
Eu tb utilizo Hibernate e acho que o ganho dele é quando usa-se um dominio totalmente OO.
O problema é que se eu usar JDBC talvez valha a pena continuar a utilizar PL/SQL.
Ou poderia criar um Service que executa o fluxo e executaria as ações via JDBC.

O que acham?

Ganhar de um acesso em cima de uma PL/SQL, bem feito obviamente, não é muito fácil mas acho que existem possibilidades.

Primeiro na minha opinião o início da viagem só vale a pena se REALMENTE tenha que passar o código PL para Java incondicionamente, ou seja, estrategicamente falando seja realmente vantajoso; porque vai requerer paciencia e atenção aguçada fora as leituras incessantes no tutorial do Hibernate.

Se as tabelas envolvidas estiverem bem normalizadas, possuirem indices adequados, o banco bem configurado e um DBA bacana que colabora (sei que estou pedindo demais rsrsrsr) não vejo necessidade de refazer toda a estrutura. O novo esquema no hibernate pode ficar mais rápido que em JDBC por causa dos caches os próximos acessos muitas vezes nem chegam até a base de dados, isso sem falar nos acessos estrategicamente configurados utilizando lazy, serviços especificos para cada tipo de consulta evitando acesso desnecessários etc… Outra coisa que pode ajudar muito são views (estrutura construida na base) que vc pode mapear depois como se fosse uma tabela normal isso dá sintese à consulta e portanto mais velocidade.

flws

Fantomas, gostei das suas idéias mto obrigado. Talvez a ideia da VIEW seja a melhor. Vou analisar aqui, porque algo que é extremamente importante é a perfomance, hoje a rotina em PL/SQL é executada em torno de 1 minuto. Utilizando Hibernate ou JDBC a mesma teria que ficar com no maximo isso. Se bem que na verdade a grande preocupação do pessoal é manter essa rotina como um SERVIÇO, para que outras aplicações executem a mesma.

Vocês já consideraram a idéia de otimizar o PL ? Ja vi casos que uma rotina demorava 20 minutos, mudada para menos de um minuto.

Faz total sentido peerless, mas parece que a idéia é se livrar do código PL/SQL ou algo bem próximo disto.

flws

Acho uma péssima idéia…

Desencapsular as regras do PL/SQL É LOUCURA…

VAI FICAR MAIS LENTO…

e o hibernet é bom mas limitado para migrar funcionabilidades do PL.

Um caso clásico é o UNION que sempre tem em PL/SQL e o hibernate não tem…

Melhor restruturar o PL/SQL e fazer o controle das chamadas em JAVA com DAO e outros pattern

Usar o Hibernet para operações de inclusão update e delete mas os find deixa no PL/SQL

bom na verdade só uma suposição… tem que ver se o PL está aproveitavel…

Se os Pls estão demorando muito com certeza é um banco sem indices, sem FK …

O pl é muito mais rápido pq ele não é interpletado, tá compilado no banco…

O embassado vai ser vc transformar os cursores e codigo tipo esse:

TO_NUMBER(TO_CHAR(umaData,‘YYYY’) || TO_CHAR(outraData,‘MM’)

e assim vai…

boa sorte…

Bom Foção, eu também acho loucura fazer essa mudança, mas eles querem por que querem tirar o PL do sistema.
Então o jeito vai ser usar Hibernate mesmo.

Mas valeu pelas dicas!

[quote=Focão]Acho uma péssima idéia…

Desencapsular as regras do PL/SQL É LOUCURA…

VAI FICAR MAIS LENTO…

e o hibernet é bom mas limitado para migrar funcionabilidades do PL.

Um caso clásico é o UNION que sempre tem em PL/SQL e o hibernate não tem…

Melhor restruturar o PL/SQL e fazer o controle das chamadas em JAVA com DAO e outros pattern

Usar o Hibernet para operações de inclusão update e delete mas os find deixa no PL/SQL

bom na verdade só uma suposição… tem que ver se o PL está aproveitavel…

Se os Pls estão demorando muito com certeza é um banco sem indices, sem FK …

O pl é muito mais rápido pq ele não é interpletado, tá compilado no banco…

O embassado vai ser vc transformar os cursores e codigo tipo esse:

TO_NUMBER(TO_CHAR(umaData,‘YYYY’) || TO_CHAR(outraData,‘MM’)

e assim vai…

boa sorte…
[/quote]

Hibernate bem cacheado pode ter melhor performace que PLs, sem contar que chamar uma PL e esperar o resultado já vale o tempo para começar a usar hibernate. E a proposito, qual é a idéia do uso do hibernate mesmo? :wink:

O bom disso tudo é que convenci meu chefe a “abondanar” o legado e começarmos uma aplicação nova do zero. Esperamos agora usar OO de verdade