RE: [oracle_br] Re: Regra de n egocio na aplicação ou no banc o de dados ?

2016-04-05 Por tôpico Dalton Oliveira dalton_olive...@hotmail.com [oracle_br]
Tudo tranquilo Chiappa!!! 
Como de costume, vc sempre com respostas completas e bem embasadas.
Obrigadão!!!

 
Atenciosamente,
Dalton Pereira Oliveira

To: oracle_br@yahoogrupos.com.br
From: oracle_br@yahoogrupos.com.br
Date: Tue, 5 Apr 2016 05:50:26 -0700
Subject: [oracle_br] Re: Regra de n egocio na  aplicação  ou no banc o de dados 
?














 

 



  



  
  
  Bom dia, tudo jóia ? Sim, tenho que concordar com você, o cara está 
falando asnices : pra começar, vcs (corretamente!) foram aproveitar os recursos 
de performance do RDBMS Oracle ao se centralizar processamento no banco de 
dados (pelos quais JÁ PAGARAM, e não Foi pouco!!) como os caches específicos 
para PL/SQL que o RDBMS mantém, a ** proximidade ** dos dados com o código 
(pois como ambos rodam no mesmo servidor há MUITO MENOS tráfego de rede - não 
dá pra comparar isso com o tempo que se gasta tendo que ENVIAR os dados pela 
rede até o servidor onde roda a aplicação), ARRAY PROCESSING/bulk 
(provavelmente), etc & tal , e pelo jeito isso foi bem implementado, por alguém 
que sabia o que fazia e em consequencia vc teve melhoria de performance - aí o 
sujeitonho vem e detona, desprezando a melhoria de performance líquida e certa 
que vcs já obtiveram ??? Em troca de uma *** PROMESSA ** futura de "melhoria no 
padrão"?? Não dá pra engolir não...  
 E nem falei de pontos como a separação de tarefas (em vc concentrando lógica 
do negócio/processamento interno de dados/controle de Transações com 
especialistas SQL e PL/SQL vc deixa os desenvolvedores comuns focados em UI e 
processamento local, que é o que eles conhecemvia de regra), e a SEGURANÇA que 
vc adquire contra obsolescência de tecnologia : pois com TOTAL CERTEZA, se vc 
hoje tem o grosso dos seus códigos no database, se amanhã a sopinha de letras 
tecnológica muda e ao invés de X se passar a adotar a solução Y para 
front-end/apresentação/reporting o PL/SQl e o SQL é o mesmo, RIGOROSAMENTE NÃO 
MUDA Só vejo vantagens (em retorno de investimento, performance, segurança, 
etc) em se ter aplicações database-centric... Front-ends, frameworks e cia bela 
mudam quase toda hora, mas banco de dados é banco de dados
 
 Eu se fosse vc reportava esses pontos todos pra sua direção, ** PROVANDO ** no 
possível (com execuções controladas, com reports técnicos, etc) a diferença / 
lucro em termos de performance E de separação de jobs/garantia contra 
obsolescência / etc que vcs obtiveram, e a direção que decida... MUITO 
PROVAVELMENTE eles vão decidir (já que contrataram o tal consultor) por fazer 
besteira e desmanchar o trabalho que vcs já fizeram, mas pelo menos a tua 
obrigação como técnico, de apontar o melhor caminho pra Empresa (e ** não ** a 
modinha tecnológica du jour !!) vc fez...

 []s

   Chiappa



 









  

[oracle_br] Re: Regra de n egocio na aplicação ou no banc o de dados ?

2016-04-05 Por tôpico jlchia...@yahoo.com.br [oracle_br]
Bom dia, tudo jóia ? Sim, tenho que concordar com você, o cara está falando 
asnices : pra começar, vcs (corretamente!) foram aproveitar os recursos de 
performance do RDBMS Oracle ao se centralizar processamento no banco de dados 
(pelos quais JÁ PAGARAM, e não Foi pouco!!) como os caches específicos para 
PL/SQL que o RDBMS mantém, a ** proximidade ** dos dados com o código (pois 
como ambos rodam no mesmo servidor há MUITO MENOS tráfego de rede - não dá pra 
comparar isso com o tempo que se gasta tendo que ENVIAR os dados pela rede até 
o servidor onde roda a aplicação), ARRAY PROCESSING/bulk (provavelmente), etc & 
tal , e pelo jeito isso foi bem implementado, por alguém que sabia o que fazia 
e em consequencia vc teve melhoria de performance - aí o sujeitonho vem e 
detona, desprezando a melhoria de performance líquida e certa que vcs já 
obtiveram ??? Em troca de uma *** PROMESSA ** futura de "melhoria no padrão"?? 
Não dá pra engolir não...  
 E nem falei de pontos como a separação de tarefas (em vc concentrando lógica 
do negócio/processamento interno de dados/controle de Transações com 
especialistas SQL e PL/SQL vc deixa os desenvolvedores comuns focados em UI e 
processamento local, que é o que eles conhecemvia de regra), e a SEGURANÇA que 
vc adquire contra obsolescência de tecnologia : pois com TOTAL CERTEZA, se vc 
hoje tem o grosso dos seus códigos no database, se amanhã a sopinha de letras 
tecnológica muda e ao invés de X se passar a adotar a solução Y para 
front-end/apresentação/reporting o PL/SQl e o SQL é o mesmo, RIGOROSAMENTE NÃO 
MUDA Só vejo vantagens (em retorno de investimento, performance, segurança, 
etc) em se ter aplicações database-centric... Front-ends, frameworks e cia bela 
mudam quase toda hora, mas banco de dados é banco de dados
 
 Eu se fosse vc reportava esses pontos todos pra sua direção, ** PROVANDO ** no 
possível (com execuções controladas, com reports técnicos, etc) a diferença / 
lucro em termos de performance E de separação de jobs/garantia contra 
obsolescência / etc que vcs obtiveram, e a direção que decida... MUITO 
PROVAVELMENTE eles vão decidir (já que contrataram o tal consultor) por fazer 
besteira e desmanchar o trabalho que vcs já fizeram, mas pelo menos a tua 
obrigação como técnico, de apontar o melhor caminho pra Empresa (e ** não ** a 
modinha tecnológica du jour !!) vc fez...

 []s

   Chiappa