O que é mais dificil?

Bom, eu não sou experiente, mas tenho uma pequenina experiencia para compartilhar:

Numa empresa foi necessário integrar duas aplicações diferentes (uma em java e outra em … vb). O fato de ser o mesmo banco de dados para ambos (sqlserver2000) facilitou bastante o processo.

Mas acredito que o ideal seja não precisar mudar absolutamente nada. Ao trabalhar em camadas, não importa a tecnologia do banco de dados ou da aplicação, a coisa toda deveria continuar a funcionar.

Viva os padrões o/

Realmente essa é uma dúvida bastante interessante. Mas eu acho que a idéia principal de deixar as regras na aplicação, não é quando você trabalha com apenas 1 cliente utilizando essa aplicação. A idéia aqui é utilizar uma aplicação ou componentes dessa aplicação em vários clientes.

Por exemplo. Tenho um componente que gera Notas e Faturas no meu Cliente X. Eu desenvolvi em PostgreeSQL, mas o meu cliente já tem as licenças do Oracle e quer que o sistema rode em Oracle, sem problemas, vamos por o sistema pra rodar em Oracle.
Agora quero usar o mesmo componente em outro cliente que vai usar uma solução mais barata ou free (firebird,mysql ou o próprio PostgreeSQL), sem problemas, nossa aplicação rodará em qualquer banco de dados .

Principalmente com as divisões de camadas e criação de componentes, fica mais fácil de reutilizar funcionalidades em outros sistemas e em clientes diferentes.

Hummmm … até hoje nunca vi ninguem fazendo uma mudança drástica no servidor do banco de dados (drástica = do Oracle para o SQL Server) mas já vi jogarem fora toda a estrutura VB e reescreverem em Java

O principal motivo que eu vi pra não mudar de banco de dados seria que no geral as aplicações não são portáveis e exigiram esforço/investimento para mudar o banco.

Se você escreve uma aplicação portável eu conto isso como uma vantagem (o Oracle tá caro? Dane-se, põe o XYZ) … mas dependendo da situação eu acho que vale a pena (e muito) usar recursos específicos do sgbd.

Falei falei e nao disse nada?

Bem, respondendo:

1. É mais difícil ver a troca do banco de dados
2. Use um desenho portável onde portabilidade é desejado, caso contrário tasca recursos proprietários se isso for fazer sua aplicação muito melhor desenhada e com performance mais satisfatória.

PS: Não tenho tanta experiência assim tb … pode ser que exista muita gente pulando de galho em galho com fornecedores de SGBD, mas eu não vi

Hmm, realmente está é uma questão bem complexa…
Entretanto, na minha opinião, se vc coloca a regra de negócio no BD (em triggers e/ou procedures) vc acaba perdendo uma das camadas.

Ao menos quando olho para a arquitetura três camadas não vejo apenas uma divisão de responsabilidades, mas também a capacidade de intercambiar essas camadas livremente (pelo menos seria isso o ideal). E no momento que vc coloca a base de dados e as regras de negócios no mesmo ambiente vc vincula uma a outra. Como posso trocar a base de dados sem reescrever as regras de negócio???

Mas isso dá muito pano pra manga…

O difícil da questão é que não importan o quanto a IBM, Oracle, etc. vendem APplication Servers, eles também vendem DB2 e escrevem na documentação que “você é um idiota se não colcoar sua lógica no nosso SGBD”.

Bom, acho que existe uma pequena confusão. A lógica, num modelo de camadas, não fica na apresentação nem no bd, fica na camada de negócios.

J2EE é exatamente sobre isso. Você é [seria, em teoria ao menos] capaz de mudar sua apresentação [maldito HTML, Swing, cadê vc?], seu servidor de aplicações [WebEspirro nunca mais! WebIlógico é a bala de prata!] ou de SGBD [o que? DB2? Nem se fosse 2000, essa porcaria nao serve, põe um SQL Servo aí! - br… péssimo exemplo… e sua lógica ficaria igual [mudar de Java para outra tecnologia éoutro papo] e deveria rodar perfeitamente. Por isto que tudo é padronizado. Quem já trabalhou acessando um SGBD diretamente com C/C++ tem noção da bosta que é quando cada um faz um padrão diferente…

Considere encapsulamento.

private int numeroSecreto

Vamos supor que número secreto tenha que ser entre 3 e 30, não mais, não menos. COmo eu garanto isso OO? Fàcil, ponho ele privado e faço a verificação no método. Bem, nosso número vai pro BD alguma hora. Se eu mexer nele através de StoredProcedures, estou mainipulando o estado, não o objeto. Isto pdoe detonar um modelo.

Ok, só vamos fazer alterações no BD por stored procedures, e vamos colocar nas stored procedures a mesma regra que no objeto. Ops, lógica idêntica duplicada em dois lugares, putz, não presta isso!

Esquece! Dexia tudo acessível mesmo, é responsabilidade do programador não alterar para valores proibidos. Mas… se é pra fazer assim, por que usar private? Usa public logo e o cara que se coce para manter o objeto válido!

Fora que se você fizer um mapeamento de heranças, pode acabar corrompendo todo o modelo porque você vai lidar comd ados, não com objetos. O cudiado tem que ser muito alto…

É claro que se você precisa de desempenho, pdoe abrir mão de algumas coisas. Se você rpecisa que determinados dados sejam pesuisados, manipulados, sei lá, você pode escrever uma SP com cuidado e correr o risco de acabar fazendo alguma besteira no caminho, em prol da velocidade. as vezes é necessário…

é para isto que existem camadas, povo.

[]s

Eu vejo que desenvolver usando recursos proprietarios do banco somente é vantagem quando é para uso interno e já existe investimento pesado com um fornecedor.

Porém se voce está desenvolvendo um produto, eu pessoalmente vou ai depilar todos os pelos do seu corpo com pinca de sombrancelha se voce fizer esse tipo de burrice.

No começo do ano passado estava trabalhando em um cliente que foi OBRIGADO a comprar algumas licensas de oracle por que o IDIOTA o sistema adquirido era TODO desenvolvido em SP Oracle.

O Cliente tem uma parcela de culpa nisso também… ninguém mandou Ele comprar uma solução que ultilizava funcionalidades proprietárias

Mas se o teu diretor de TI resolve fazer o que fizeram aqui na empresa…oh o proximo sistema não será mais Java e sim .Net. E dai como fica? Aqui na empresa ta ocorrendo isso. Advinha pq naum mexemos na camada de negocio ainda?

É uma duvida cruel…a meu ver. Eu gostaria de colocar na camada dele, ou seja de negocios e a cada troca de front end, tecnologia e tal eu ter mais trabalho pra desenvolver…

]['s

“fabgp2001”:

Mas se o teu diretor de TI resolve fazer o que fizeram aqui na empresa…oh o proximo sistema não será mais Java e sim .Net. E dai como fica? Aqui na empresa ta ocorrendo isso. Advinha pq naum mexemos na camada de negocio ainda?

Plagiando alguém daqui [acho que o cv] e se o servidor derreter por radiação solar? e se o abominável homem das cavernas vier morar no friozinho do datacenter? Ó vida, ó céus

Na verdade, existem até disciplinas em engenharia de software sobre gerência de mudanças, ams elas existem. E se trocarem seu bandco? Difícil? Duvido muito, deixa seu CIO sentar do lado de um vendedor de DB2 por dois minutos e vc tem trabalho pro ano todo…

A questão é focar em uma arquitetura onde as mudanças impactem o menos possível. Seu gerente tb poderia mandar vc mudar o SGBD, o front-end… riscos nós tenmos que correr

[]s

“pcalcado”:

“fabgp2001”:

Mas se o teu diretor de TI resolve fazer o que fizeram aqui na empresa…oh o proximo sistema não será mais Java e sim .Net. E dai como fica? Aqui na empresa ta ocorrendo isso. Advinha pq naum mexemos na camada de negocio ainda?

Plagiando alguém daqui [acho que o cv] e se o servidor derreter por radiação solar? e se o abominável homem das cavernas vier morar no friozinho do datacenter? Ó vida, ó céus

Na verdade, existem até disciplinas em engenharia de software sobre gerência de mudanças, ams elas existem. E se trocarem seu bandco? Difícil? Duvido muito, deixa seu CIO sentar do lado de um vendedor de DB2 por dois minutos e vc tem trabalho pro ano todo…

A questão é focar em uma arquitetura onde as mudanças impactem o menos possível. Seu gerente tb poderia mandar vc mudar o SGBD, o front-end… riscos nós tenmos que correr

[]s

hehe essa foi boa…mas serio se tu visse meu diretor tu naum diria isso. Fui mandado em bora pq naum queria usar .net, mas voltaram atras pq precisavam de mim.
Eles até cogitaram trocar o banco, mas viram o $$ que iriam gastar e desistiram.

Eu adoraria trabalhar em um arquitetura perfeita. Mas sou sincero até hoje não passei nem perto. Por isso coloquei o post pra ver o que o pessoal ta acostumado a ver por ai.

A não me joguem na cruz, nos meu bicos a camada de negocio não fica no DB mesmo eu tendo comecado a programr só em banco.

]['s

É brabo, né Fábio, cabeça de CIO é terreno inexplorado, a gente nunca consegue prever estes carinhas… mas prover pontos de extensibilidade no sistema é uma boa [nada de exagero, nada de generalizar tudo, NADA DE CLASSE “PESSOA”!!]

Não adianta prever o futuro, mas é melhro projetar bem uma arquitetura, aidna mais se você vai ter que conviver com ela por muitos anos. As tecnologias vão semrpe mudar, seja o banco que agora é versão 10XYZ seja porque agora vocês vão usar o novíssimo framework ABCDE.

Mas pense: para que as camadas foram criadas?

[]s

Mudou o front-end e tem que re-escrever as regras de negocio?

Bom se sua aplicação está nesse ponto, apenas posso te desejar boa sorte pq a arquitetura inteira está errada.

Se um middle-ware tivesse sido usado logo de cara isso não seria nem uma preocupação.

Tivesse usando um app server, teu novo front-end poderia falar com o middle-tier via corba, web services ou seja lá oque for.

Vegetto, o problema é que a decisão comercial veio de cima para baixo e não foi o caso de usar funcionalidades proprietárias, mas ser 100% engessado no Oracle, 100% do business logic foi escrito em SP.

depilando os pelos do corpo para não dar trabalho a louds

:mrgreen:

pois é … às vezes não adianta argumentar

“louds”:

Mudou o front-end e tem que re-escrever as regras de negocio?

Bom se sua aplicação está nesse ponto, apenas posso te desejar boa sorte pq a arquitetura inteira está errada.

Se um middle-ware tivesse sido usado logo de cara isso não seria nem uma preocupação.

Tivesse usando um app server, teu novo front-end poderia falar com o middle-tier via corba, web services ou seja lá oque for.

Vegetto, o problema é que a decisão comercial veio de cima para baixo e não foi o caso de usar funcionalidades proprietárias, mas ser 100% engessado no Oracle, 100% do business logic foi escrito em SP.

Concordo plenamente…

No incio eu postei pra ver generico, mas acabei colocando aqui o sistema onde trabalho. Não que tudo seja ruim, longe disso.

Agora não se nos mudarmos o front-end não precisamos mudar nada nas regras de negocio, pq simples elas estão no banco. Mudar o banco …iiii f***** tem que mudar tudo. É correto eu não acho, mas quem disse que eu era programador quando fizeram a base de tudo…

Sobre o contexto em geral.
Acho que o pior não é isso, vejo muitos sistemas sendo vendidos por ai onde tudo depende do banco. Alguem aqui ja trabalhou com o ERP IFS Aplications? É tudo em rotina no Oracle. E muitos outros sistemas estão nascendo engecado no banco.
Olha quero que entendam, eu estou longe de achar isso bom. Como eu gostaria de mexer num sistema que para alterar as regras do meu negocio eu naum precisasse sair mexendo em 50 telas. E depois eu esqueco de uma ainda pago por ser ruim…hehe

Ja notei que a maioria concorda, varias camadas, regra de negocios separadas…bla bla bla…ok. Mas quantos trabalham num cenario desses? Mexem em sistemas assim?
A teoria e como deveria ser eu sei, mas até agora não consegui encontrar um sistema realmente grande feito desta maneira.

Fica ai a pergunta.

]['s

Pior a microsiga que tem uma tecnologia de banco de dados deles. Imagina tentar acoplar alguma funcionalidade àquilo … simplesmente não dá hehe

OFF: Senta no chão e chora

Bom, essa resposta vai ficar chata, mas eu ja trabalhei varias vezes em cenarios assim. Alias, qualquer sistema com um MVC bem feitinho acaba sendo modularizavel desse jeito. Mas parem de esquentar a cabeca com bancos de dados. Nao vale a pena. Deixem tudo pra um Hibernate da vida e pronto. Precisando melhorar a performance aqui ou ali, aih sim, vc vai la e da uma mexida, mas cara, tem tanta coisa mais importante pra se preocupar do que com tabelinha no banco…

Bom, essa resposta vai ficar chata, mas eu ja trabalhei varias vezes em cenarios assim. Alias, qualquer sistema com um MVC bem feitinho acaba sendo modularizavel desse jeito. Mas parem de esquentar a cabeca com bancos de dados. Nao vale a pena. Deixem tudo pra um Hibernate da vida e pronto. Precisando melhorar a performance aqui ou ali, aih sim, vc vai la e da uma mexida, mas cara, tem tanta coisa mais importante pra se preocupar do que com tabelinha no banco… :D

Aew CV…

Em java é lindo…rsrs
Mas e aqueles sistemas que o Java passa longe? E que se falar em padrão o desenvolvedor treme as pernas?
Outra coisa tu ja mexeu em sistemas assim tudo MVC, o tamanho era comparavel a um ERP?

O que o LIPE colocou ali em cima é a realidade, alguem ja brincou com Microsiga ai? Ja viu a estrutura de tudo? Bha …deixa pra la vou fazer o que o colega sugeriu…sentar e chorar hehe

]['s

Antes de mais nada, isto não é uma crítica ao Fábio, mas um comentário geral. Muitas vezes vejo aqui no fórum pessoas postando “o que voces acham de X?” e após algumas opiniões contrárias, acontece o “ah, mas vcs não trabalham com isso, não sabem como é”. Bom, eu acho que experiência é importante sim, mas quem garante que qualquer um que tenha escrito não a tenha?

Eu, pessoalmente, tenho pouca experiência [e basicamente teórica] com sistemas muito grandes, e experiência zero com ERPs. Será que todos são assim?

Além do mais, eu sou um técnico. Não posso rankear ninguém aqui [e nem quero!], mas será que invalida minha opinião? Não estamos falando de Java e Bancos de Dados? Ora, disso eu conheço!

Será que não, Fábio? Bom, EJB pode não ser a melhor maravilha do mundo [ou mesmo a pior…], mas ele foi feito para isso. Conheço gente que desenvolve tudo em CloudScape ou MySQL depois faz o deploy em DB2, Oracle… [não que sejam piores, mas são mais baratos ].

Sistemas muito grandes foram construídos usando EJB e outros frameworks J2EE, e estes sistemas, se bem projetados, deveriam seguir pelo menos o conceito de camadas. Afinal, se é para não seguir o modelo, para que J2EE? Faça tudo em cliente servidor, ora! Ou então assuma que seu servidor de aplicações é o interpretador de comandos do SGBD…

A questão é: não existem camadas se não forem definidas camadas, ué!

[]s

Interessante, a SAP, maior produtora dos elefantes brancos do mundo, também tinha, e acabou liberando o SAP DB, opa, MaxDB.

[]s

Se o produto é ruim, não tem oque ser feito mesmo, mas para muito disso o Hibernate consegue dar 1 boa diminuida no tamanho do nabo. Com J2EE vc consegue falar com sistemas legados usando a arquitetura de Connectors. Só não vou comentar pq deixo isso por conta do Daniel Quirino. hehehe

“fabgp2001”:

O que o LIPE colocou ali em cima é a realidade, alguem ja brincou com Microsiga ai? Ja viu a estrutura de tudo? Bha …deixa pra la vou fazer o que o colega sugeriu…sentar e chorar hehe
]['s

Nós fazemos isso aqui, temos clientes com microsiga, todos usando com SQLServer. Na grande maioria dos casos não fui envolvido no assunto e temos umas monstruosidades nem dignas do microsiga (relatorios com 5000 linhas no mesmo arquivo, java 100% procedural, etc), mas do pouco que eu mexi, o resultado é que custa MUITO para fazer o negocio direito.

Para aquilo que já é ruim não existe bom remédio, mas sim bom remendo.

“pcalcado”:

“fabgp2001”:

Ja notei que a maioria concorda, varias camadas, regra de negocios separadas…bla bla bla…ok. Mas quantos trabalham num cenario desses? Mexem em sistemas assim?

Antes de mais nada, isto não é uma crítica ao Fábio, mas um comentário geral. Muitas vezes vejo aqui no fórum pessoas postando “o que voces acham de X?” e após algumas opiniões contrárias, acontece o “ah, mas vcs não trabalham com isso, não sabem como é”. Bom, eu acho que experiência é importante sim, mas quem garante que qualquer um que tenha escrito não a tenha?

Eu, pessoalmente, tenho pouca experiência [e basicamente teórica] com sistemas muito grandes, e experiência zero com ERPs. Será que todos são assim?

Além do mais, eu sou um técnico. Não posso rankear ninguém aqui [e nem quero!], mas será que invalida minha opinião? Não estamos falando de Java e Bancos de Dados? Ora, disso eu conheço!

Só deixando claro, eu não quiz dizer que quem não trabalhou com sistemas assim nao tem experiencia e tal. Eu particularmente trabalhei pouco com esse tipo de sistema, mas nas andanças da vida agente sempre ve esses sistemas por ai.

“pcalcado”:

Será que não, Fábio? Bom, EJB pode não ser a melhor maravilha do mundo [ou mesmo a pior…], mas ele foi feito para isso. Conheço gente que desenvolve tudo em CloudScape ou MySQL depois faz o deploy em DB2, Oracle… [não que sejam piores, mas são mais baratos ].

Sistemas muito grandes foram construídos usando EJB e outros frameworks J2EE, e estes sistemas, se bem projetados, deveriam seguir pelo menos o conceito de camadas. Afinal, se é para não seguir o modelo, para que J2EE? Faça tudo em cliente servidor, ora! Ou então assuma que seu servidor de aplicações é o interpretador de comandos do SGBD…

A questão é: não existem camadas se não forem definidas camadas, ué!

[]s

Sou sincero, eu particularmente ainda não vi. Bem que gostaria, como eu sempre disse que eu vim do mundo dos banco de dados, to mais acostumado com ERP que tem todas regras la no banco, ja ando mei complexado com isso mas…
EJB sei o que é de teoria só isso, melhor muita coisa do mundo de Java eu conheco de estudo e teoria.

Eu particularmente uso pouco java no meu trabalho, pra não dizer nada. A unica coisa que tem java é o site do sistema que eu trabalho, ele ta rodando bem usa MVC, mas é um site pequeno e a proxima versão ta saindo em .net e eu passo longe dele agora.
Mas sou sincero em dizer, uma das coisas que mais me dão tesao de aprender Java é toda arquitetura, padrões etc. É dificil a meu ver isso ser notado em outras comunidades de desenvolvedores.

]['s

“louds”:

“fabgp2001”:

Em java é lindo…rsrs
Mas e aqueles sistemas que o Java passa longe? E que se falar em padrão o desenvolvedor treme as pernas?

Se o produto é ruim, não tem oque ser feito mesmo, mas para muito disso o Hibernate consegue dar 1 boa diminuida no tamanho do nabo. Com J2EE vc consegue falar com sistemas legados usando a arquitetura de Connectors. Só não vou comentar pq deixo isso por conta do Daniel Quirino. hehehe

“fabgp2001”:

O que o LIPE colocou ali em cima é a realidade, alguem ja brincou com Microsiga ai? Ja viu a estrutura de tudo? Bha …deixa pra la vou fazer o que o colega sugeriu…sentar e chorar hehe
]['s

Nós fazemos isso aqui, temos clientes com microsiga, todos usando com SQLServer. Na grande maioria dos casos não fui envolvido no assunto e temos umas monstruosidades nem dignas do microsiga (relatorios com 5000 linhas no mesmo arquivo, java 100% procedural, etc), mas do pouco que eu mexi, o resultado é que custa MUITO para fazer o negocio direito.

Para aquilo que já é ruim não existe bom remédio, mas sim bom remendo.

Pois é…isso que eu digo…o brabo que alem de ser assim tu tem que ir la e mexer e se der errado o cara passa por ruim ainda.

Nosssaaaaa!! J2EE Connectors é muito bem projetadinha, muito bonitinha e quebra altos galhos. Mas trabalhar com ela no dia-a-dia é uma como levar marretadas no joelho todos os dias de tão chato, tão improdutivo e difícil de testar que é. Mas, ok, se você precisar um dia conversar com um ERP da Microsiga ou da SAP (minha experiência foi com o R/3), você o faz na boa. E, inúmeras vezes, é muito útil/vital, principalmente quando uma lógica de negócios muito complexa já está implementada em algum museu como uma aplicação em COBOL e sua empresa não pode perder tempo nem se arriscar com o porte desta regra para uma tecnologia mais nova.

Mas, voltando ao assunto de se implementar regras de negócio em banco de dados ou em aplicações. Eu sou bem radical quanto isso: banco de dados não foi feito para guardar lógica de negócios, mas dados. E não discuto isso.

Deixando a regra no banco acho difícil comprovarmos que desenvolvemos um sistema OO, e por conseguinte não conseguimos garantir sua manutenibilidade.

Eita. Simples assim?

Marcio Kuchma

A frase assim colocada tem um impacto forte, né?

Mas pensando um pouquinho nem é tão absurdo: se suas regras estão no banco, o que seu código tem ? Acho difícil dizer que um sistema que possui regras no banco é OO… A não ser que utilizemos um SGBDOO, e as regras que vc colocou lá tb estejam em forma de objetos… :?

Class.forName  ("jdbc.Driver");
Connection con = DriverManager.getConnection( url, "login", "your_password" );
Statement stmt = con.createStatement ();
ResultSet rs = stmt.executeQuery (query);

…e só!

:lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol:

[]s

Ah, não exagerem, quando as regras tão no banco o desenvolvedor tem que ser um profundo conhecedor do protocolo SPCSPL*

*String Pra Ca String Pra La ™ CV productions, All right reserved

“oazuc”:

A frase assim colocada tem um impacto forte, né?

Mas pensando um pouquinho nem é tão absurdo: se suas regras estão no banco, o que seu código tem ? Acho difícil dizer que um sistema que possui regras no banco é OO… A não ser que utilizemos um SGBDOO, e as regras que vc colocou lá tb estejam em forma de objetos… :?

A primeira parte eu entendi. O que eu nao entendi foi a segunda parte da sentenca.

Mas nao vamos desvirtuar o topico…

Marcio Kuchma

Tentando trazer mais para o objetivo do tópico:
se de repente seu sistema for todo construído utilizando Stored Procedures ou algo do tipo, fica complicado trocar, por exemplo, o banco de dados.

O comentário sobre manutenibilidade foi baseado justamente nesse aspecto, já que a Orienteação a Objetos foi concebida levando em consideração a facilidade de manutenção. Assim, é um pouco estranho colocar suas regras no banco, pois apesar de não mudarem muito, sinceramente não sei dizer se uma SP é desenvolvida utilizando OO (e se alguém for colocar alguma regra no banco, por favor, coloque toda ela ou documente muito bem, pois poderei ser o próximo a dar manutenção nesse sistema)

Bom, produtos como o DB2 permitem SPs em Java, por exemplo. Acho que o Oracle tb.

Nunca fiz uma assim, e acho que isto eliminaria um pouco dos problemas. Seu SGBD seria um AS, e poderia [hipótese] manter um comportamento OO.

A questão é: o quão portável é isso? Quantos SGBDs têm isso? Vale a pena?

Acho que esta tecla está repetitiva já…

O que posso afirmar:

Às vezes, por questões de performance, é interessante ter uma SP manipulando dados diretamente. O problema é que as pessoas abusam disso e fazem do SGBD seu Application Server.

Quando você faz uso de StoredProcedures, está pensando proceduralmente, num mundo preto-e-branco onde dados ficam num canto e operações em outro. Você corre o risco de quebrar seus objetos desta forma e não conseguir colar depois.

Regrinhas para uso de SPs:

- M.A. Jackson

But I also knew, and forgot, Hoare’s dictum that premature optimisation is the root of all evil in programming.

[]s

Class.forName  ("jdbc.Driver");
Connection con = DriverManager.getConnection( url, "login", "your_password" );
Statement stmt = con.createStatement ();
ResultSet rs = stmt.executeQuery (query);

…e só!

:lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol:

[]s

Essa foi boa…

Bom, produtos como o DB2 permitem SPs em Java, por exemplo. Acho que o Oracle tb.

Nunca fiz uma assim, e acho que isto eliminaria um pouco dos problemas. Seu SGBD seria um AS, e poderia [hipótese] manter um comportamento OO.

A questão é: o quão portável é isso? Quantos SGBDs têm isso? Vale a pena?

Sinceramente, esqueca essa parte…java no banco na minha opinião é uma m****.

“pcalcado”:

O que posso afirmar:

Às vezes, por questões de performance, é interessante ter uma SP manipulando dados diretamente. O problema é que as pessoas abusam disso e fazem do SGBD seu Application Server.

Quando você faz uso de StoredProcedures, está pensando proceduralmente, num mundo preto-e-branco onde dados ficam num canto e operações em outro. Você corre o risco de quebrar seus objetos desta forma e não conseguir colar depois.

Regrinhas para uso de SPs:

- M.A. Jackson

But I also knew, and forgot, Hoare’s dictum that premature optimisation is the root of all evil in programming.

Donald Knuth’s “The Errors of TeX”

[]s

E o pessoal exagera mesmo.
O ideal seria utilizar o banco somente quando precisar maninupular uma grande quantidade de dados e que colocanco nele o sistema tenha um significativo ganho na performance.

]['s

Vale lembrar também que o mais próximo de um deadline que o Don Knuth chegou a vida toda foi o filme…