Olá caros colegas desenvolvedores. Vocês que já são experientes em java recomendam a escrita das regras de negócio em stored procedures ou nas classes java ?
Minhas regras de negócio executa centenas de querys em banco de dados para serem realizadas.
Ai pensei que o mais natural seria escrever as regras todas diretamente no banco. Mas eu acabaria tendo código duplicado como é o caso dos CRUDs.
Alguém sabe se a stored procedure pode ser deixada de lado ?
Já fiz esta pergunta para várias pessoas e a resposta sempre vem uma padrão.
Depende.
Algumas regras tem que estar na classe e no banco outras só na classe.
Na teoria se vc criar só na classe seu sistema já fica OK, mas neste caso um sistema de terceiro, ou um cara usando o banco diretamente ou um erro seu pode rodar ações não válidas no seu banco (De acordo com a sua regra de negocio)
Obrigado,
Marcelo Gomes
Boa tarde larini,
Utilizações de Triggers (gatilhos) que a cada regra ela seria disparada para verificar o que estivesse realizando.
Da uma olhada sobre criação e manipulação de triggers. Vale ressaltar que ela é aplicada para cada tabela do seu banco
Espero ter ajudado,
Na minha opinião, em poucos casos vale a pena usar stored procedures. Que apesar de serem mais rápidas, amarram a regra com o banco de dados e são mais difíceis de dar manutenção e serem testadas. Diferente da regra no código java, que pode ser validada com testes de unidade, e dependendo da forma que você desenvolveu, o código pode também ser reaproveitado em outras regras, etc.
Pois é, mas eu tinha um código em java que reescrevi em stored procedure, e ficou aproximadamente 10 vezes mais rápido… Dai pra frente o pessoal quer stored procedure sempre.
Bom, eu citei que stored procedures são mais rápidas, mas depende muito o caso também. Certa vez eu usei uma solução de cache com JBossCache e evitei o banco de dados. Muito provavelmente(depende o caso) fica mais rápido que uma solução procedure, pois os dados já estão na memória.
Mas existem outras forma de otimização do código. Não vejo sps como a melhor forma. Pode chegar um momento que sua aplicação fique muito dependente do banco de dados. Ai vai ficar difícil de escalar, dar manutenção, etc.
Teve uma discussão bem grande aqui no GUJ sobre isso, dê uma olhada:
[quote=Bruno Laturner]Teve uma discussão bem grande aqui no GUJ sobre isso, dê uma olhada:
http://www.guj.com.br/posts/list/8443.java[/quote]
mas lembre-se, essa discução foi a 5 anos, e nesse tempo, muita coisa pode rolar, e muito das opiniões das mesmas pessoas podem ter mudado
afinal estamos falando de tecnologia, e 5 anos em tecnologia é uma eternindade ^^ (não que esteja dizendo que vc deva descartas as opiniões, e sim anilizar com cuidado e trazelas para atualidade) …
Ps.: eu ainda não li a discução, so vi q era antiga, to lendo agora…
…
e a minha opinião é que vc deva deixar a logica no Java, se puder evite o stored produce… mas não sou nenhum especialista
Essa história de regra de negocio em Stored Procedure era moda ha uns 8 anos atras no VB, ASP, são poucos casos que vale a pena usar tal procedimento, se for possível use Hibernate e deixe sua aplicação independente de banco de dados, aqui mesmo tive um caso que para montar um arquivo a Stored Procedure demorava 1 segundo por linha, se o arquivo tivesse 1000 linhas imaginem em uma aplicação WEB, coloquei no Java e monta em 2 segundos essas 1000 linhas.
Caro larini,
Conversei com o DBA (MCP, MVP SQL SERVER) da empresa em que trabalho e ele me disse que, a melhor opção de tratar as suas regras de negócio é na aplicação, agora se você deseja amarrá-las ao banco de dados então, continue utilizando Stored Procedures que é a forma mais rápida de utilização do banco de dados a regras.
Espero ter ajudado,
Pelo que vi vocês preferem que as regras fiquem no Java. Mas posso dizer com certeza, quando o processo era no java, o banco de dados não passava de 5% de utilização. Tipo assim, o cliente tem uma puta máquina de milhões de dólares (literalmente) e fica sobrando…
[quote]
Pelo que vi vocês preferem que as regras fiquem no Java. Mas posso dizer com certeza, quando o processo era no java, o banco de dados não passava de 5% de utilização. Tipo assim, o cliente tem uma puta máquina de milhões de dólares (literalmente) e fica sobrando…[/quote]
Mas ai você não pode pensar em clientes de forma não generalizada, você tem que imaginar clientes em um todo e sua aplicação ser viável para tudo e para todos.
Tratar regras de negócio na aplicação faz com que você diminua recursos de rede!
Agora se você possui um bom investimento para o seu Servidor de banco de dados e Infra-Estrutura onde você quer restringir tudo nele então vá em frente e “meta bronca nas Stored Procedures”.
Cada caso é seu caso. Aqui tb temos uma máquina de milhões, mas a regra é que as aplicações pensem bem antes de usá-la. Regras de negócio no banco, quase nunca.
Eu acho que se você trabalha numa empresa grande e que mudanças na teconologia dos seus produtos são muito raras, acho que vale muito jogar o processo inteiro para o banco, dependendo do processo. Se forem coisas simples, acaba sendo mais trabalhoso você ficar distribuindo assim suas regras de negócio.
Agora, fazer isso trabalhando em software house, eu vejo como suicídio. Esse é um perfil de empresa que está sempre mudando de tecnologia. O trabalho adicional gerado devido a essa distribuição será enorme. Você vai praticamente ter que manter uma equipe para poder realizar essas migrações, sem que os projetos da empresa sejam penalizados.
[]'s.
oi
acho que vocês só esqueceram de considerar dois itens, tempo e entendimento da tecnologia
na pressa vai ser feito usando aquilo que a equipe domina