Opa, bom dia Dalton! Confesso que não vi o vídeo (aqui no momento não é possível vê-lo...), mas pelos comentários do Ângelo, deu pra "captar" do que se trata, e compartilho da opinião/sugestão do Ângelo...
Aqui onde trabalho, estamos migrando de Oracle Forms + SGBD Oracle, para C# (Microsoft Visual Studio) + SGBD Oracle. Há toneladas de Packages, Procedures e Functions no banco, o que facilita por um lado (questão de performance, transações de rede, etc). Mas a tendência é realmente esta que o Angelo comentou... Estamos abordando a arquitetura MVC, usando Webservices e rotas restful, em um novo sistema pra Web, e aos poucos estamos tirando as regras de negócio do banco, e migrando-as devidamente para as camadas Model/View/Controller. Ficando o SGBD mais com o papel de repositório de dados mesmo, e não repositório de lógica e regras. A princípio, o principal "medo" é que a aplicação se torne lenta. Mas com o tempo fica similar ou mais performática até, pois vc tem mais recursos para balancear a carga (API Back-End, Front-End, os Webservices, e o próprio SGBD também...). Depois de 15 anos trabalhando com banco Oracle e desenvolvimento procedural (Forms/Reports), eu admito que tinha uma certa resistência neste ponto de tirar a lógica e as Stored Procedures do banco... Mas com a abordagem Orientada a Objetos, e os fantásticos recursos da arquitetura MVC e de linguagens OO tipo C# ou Java, hoje eu conheço um pouco dos dois mundos, e posso dizer que a migração é igual injeção, rsrs: Dói, mas cura a sua aplicação ou Sistema de Gestão de uma forma muito impressionante e positiva. Minha sugestão: Vá para o caminho de migração da lógica para Webservices e para a arquitetura MVC, com abordagem restful, e aos poucos vá tirando a lógica e regras do SGBD, sempre aos poucos para ir analisando a curva de performance. Na ponta final, vc terá uma aplicação flexível, menos engessada ou amarrada ao banco, performática e através de um Hibernate ou nHibernate, vc fará o mapeamento com o banco, e como "mágica" tudo será devidamente recuperado, processado nas camadas supracitadas, e posteriormente salvo no banco, que terá um papel mais de repositório do que de lugar para lógica e regras negociais... PS: Mas é assunto que dá pano pra manga, viu? Toda mudança de abordagem, paradigma, tecnologias, tem este aspecto polêmico. Haja visto que o kernel de sistemas de muitas corporações gigantes, ainda seja o velho e bom COBOL... Abraços!! Em 5 de abril de 2016 09:30, angelo angelolis...@gmail.com [oracle_br] < oracle_br@yahoogrupos.com.br> escreveu: > > > Dalton, > > Prepare-se para receber diversas opinioes com visoes diferente do assunto. > > Muita gente tem essa visao de nao criar SPs no banco pra nao ficar muito > amarrado a plataforma. > > Por outro lado, usar e abusar dos recursos da plataforma trazem inumeras > vantagens, o custo é ficar amarrado. > > Interessante é a proposta do modelo mvc, ja viu? > > Melhor ainda se, no mundo perfeito, partissem pra webservices e o > aplicativo ficar agnóstico nao amarrado a ninguem só a metadado.. isso o > restful api ta matando a pau hoje em dia, por exemplo > > Mas pro dba que só administra a base no dia dia nao muda muito.. tudo isso > q falei la em cima vai cair numa insert ou select. > > On Tuesday, 5 April 2016, Dalton Oliveira dalton_olive...@hotmail.com > [oracle_br] <oracle_br@yahoogrupos.com.br> wrote: > >> >> >> Pessoal, bom dia!!! >> >> Qual a opinião de vocês sobre regra de negocio no banco de dados? >> >> A empresa que trabalho contratou uma consultoria e o cara "detonou" nosso >> modelo de desenvolvimento, pois desenvolvemos muito no banco de dados. >> Temos diversas rotinas que processamos em procedures e funções para ter >> desempenho. Antes algumas dessas rotinas eram no aplicativo e demorava >> muito tempo, no banco de dados o processamento é muito mais rápido. >> >> Olhem o video do consultor. >> >> https://www.youtube.com/watch?v=9hYgzPZPFVY >> >> Na minha modesta opinião, acho que ele só sabe o que é select, insert e >> delete. Não tem nenhum conhecimento de BD. >> >> O que vcs acham ? >> >> Att, >> >> >> Dalton >> >> > -- Atenciosamente, *Gustavo Guedes de Sene*
