Vou analiar duas maneiras diferentes de realizar uma tarefa, e minha dúvida reside em qual optar:
A tarefa: fazer acesso a um banco de dados, definir algumas regras de negócio, retornar alguns muitos valores.
Maneira 1: deixar todas as regras de negócio e acesso aos dados dentro de stored procedures.
Maneira 2: não fazer m* nenhuma com stored procedures, mas sim definir as regras de negócio e acessar os dados com Java.
Considerando que o server usa win2000 server com sql server 2000, as seguintes dúvidas: Qual a maneira mais rápida?
Qual a mais segura?
Qual a mais simples de desenvolver?
Qual a mais simples de dar manutenção?
Qual é mais docinha e explode na boca?
mete tudo num JSP ou numa telinha gerada pelo netbeans, jbuilder ou vep, e foda-se
erhm, tah, a maneira mais rapida seria usando uma ferramenta porrada pra te gerar o mapeamento OO/relacional, e os objetos. Ou seja, um desses “gerar entity bean a partir da tabela…”, ou as ferramentas que ja vem no Hibernate.
Entity EJBs num application server bom (o que exclui, erhm, todos os application servers disponiveis :D), ou, sei la, um DAO bem feitinho (coisa tao rara quanto um appserver razoavelmente configurado).
Hibernate, ou dependendo das tuas ferramentas, entity beans
Hibernate
(coro de 5 mil criancas com caras felizes e a boca toda melecada): HIBERNEEEEEITEEEEE!!
Eu utilizaria EJBs para fazer as regras de négocio, não costumo utilizar SPs porque sempre que as utilizo a empresa que eu estou resolve migrar o banco de dados e lá vai eu refazer as milhares de procedures. Então na minha opinião a melhor, mais segura é utilizando EJBs. Uma boa opção de velocidade nos dados é perstencia.
Hmm. E o que vc faz se tiver que trocar de banco ou se tiver que distribuir a carga de processamento das regras de negocio pra outras maquinas fora da sua rede? KABOOOOOM.
Legal, mas o seu argumento eh uma bosta. Simples assim. O que vc queria era usar session bean + webservices, ou um rule engine, e nao um amontoado de stored procedures.
PS: nao tentem me convencer de que stored procedures sao uma boa ideia. Eh perder tempo. Serio. Gato escaldado tem medo ate de agua fria
Acho que se você vai amarrar em algum lugar, amarra na linguagem e não no banco de dados. Se vamos desenvolver pensando em reutilização, por que não utilizar todos os recursos que uma linguagem possa nos dar para isso?
Amarrando as regras de negócio no banco de dados estaremos criando uma forca: a tendência dos BDs com a criação destes frameworks para acesso a dados, vai ser ficar cada vez mais independente da aplicação… Imagine-se daqui a 5 anos reescrevendo suas Stored Procedures
Ei oazuc, os caras aqui e vc me convenceram… Mas que fique claro que eu acho que a merda de usar asp é tão grande que tende ao infinito, logo usando stored procedures ou não, não vai tirar-nos da merda
Caramba cv, vc vem com os dois pés no peito…rs :shock:
Meu, acho que ninguem troca de banco como troca de cueca, pelo menos grande parte das empresas que conheço, nunca trocaram de banco. É mais facil vc encontrar um banco para varias linguagens…
No caso de distribuição do processamento, acho que é coisa do grid computing, ou to falando merda ?..rs…
Ah, num fala mal das procedures… :roll:
Acho que uma boa distribuição nao faz mal a ninguem. Ateh hj ninguem reclamou
Mas é serio cv, acho que é mais facil ( e certo ) vc ter uma base com seus dados e regras para poder ser livre e facil desenvolver seus fronts… :roll:
Estou vivendo um inferno destes…
Tenho um produto que é um sistema de gestão estratégica e como tal, deve se adequar a qualquer tipo de empresa certo???
este produto não foi “encomendado” por um cliente.
pois é…
Tinhamos o Sistema todo em procedures para ORACLE.
Resultado.
1º Cliente - SQLServer
2º Cliente - SyBase
3º Cliente - ORACLE :twisted:
Simplesmente um inferno criar toda regra pra cada banco…
hehe eu não sei se entenderam minha queixa, mas eu sou contra usar stored procedures para tudo exatamente pelo que falaram … e principalmente por causa da bagunça … se ficar 1 semana sem olhar para o código não entendo mais nada depois … mesmo com mais linhas de comentários do que de código :mrgreen:
Um “causo” pra vc: numa empresa em que eu trabalhava, um belo dia desses o diretor-geral-mega-master-pokemon-evoluido proclamou “não usamos mais nada proprietário”. Advinha o que aconteceu com as TONELADAS de procedures dentro do SQLServer?
Tah, tudo bem, mesmo assim, o seu argumento eh valido: eh bem mais comum usar varias linguagens pra um banco de dados. Mas se todo mundo se jogar da ponte, vc vai simplesmente se jogar tambem? Que custa colocar o diacho da regra de negocio dentro de uma aplicacao J2EE, e dar uma camada de webservices pra que as outras linguagens possam acessar? Assim, a sua regra de negocios fica em um lugar, os dados em outro, e todo mundo fica feliz. Alem das suas aplicacoes como um todo se tornarem bem mais faceis de gerenciar.
Ah, claro, mais uma vantagem: usando J2EE direito, vc fica independente de banco de dados e tambem de application server.
Pode ser, mas nem eh necessario chegar a esses extremos. Afinal, tem muita regra de negocio em que um middleware (no caso, o servidor de aplicacoes) pode processar muito bem, com uma grande vantagem sobre fazer tudo no banco de dados: o appserver estah mais proximo do cliente do que o banco. Alem, eh claro, de vc ter uma linguagem estupidamente mais expressiva pra modelar as suas regras de negocio (convenhamos, quem programou em PL/SQL sabe do que eu tou falando ;))
[quote=“brlima”]Ah, num fala mal das procedures… :roll:
Acho que uma boa distribuição nao faz mal a ninguem. Ateh hj ninguem reclamou [/quote]
Ate hoje ninguem reclamou da gravidade tb, mas eu particularmente nao acho ser legal ser puxado pra baixo o tempo todo. Se ninguem reclamou eh pq ninguem percebeu que uma arquitetura com mais camadas te da muito mais flexibilidade, quando o seu software eh bem feitinho.
Ter uma base com os dados, legal. Ter outra base com as regras (nesse caso, o seu application server), melhor ainda.
Serio, ate hoje ninguem me deu um exemplo onde eh irrefutavelmente melhor usar uma stored procedure. Nem mesmo quando se fala em performance. Ninguem me mostrou ate hoje o mesmo codigo escrito com Session + Entity ou Session + Hibernate e stored procedures, chegou pra mim com dados REAIS* de performance e me disse “eh, fodeu.”
*REAIS = verificaveis. Eu quero poder ir ate a maquina e ver as configuracoes todas, caching, pooling, controle de transacoes, tudo.
Em aplicações feitas sob medida para uma unica empresa…essas que elas pagam uma grana preta para desenvolver…o melhor é deixa no banco mesmo. Me diz ai qual empresa que troca de banco de dados? Eu perticularmente não conheco nenhuma.
Agora se vc vai desenvolver uma aplicação para vender…no banco só se for loco…
Sei que o pessoal do naum curte muito largar no banco os SQL, por causa de reusabilidade do código…isso até é uma verdade, mas que estando no banco é mais rapido isso sem duvida. Ainda mais se o baco for Oracle.
