Re: [oracle_br] RE: [oracl e_br] Regr a de negoc io na apli cação ou n o banco de dados?

2016-04-06 Por tôpico Andre Luiz Reis Marques aandre...@yahoo.com.br [oracle_br] 
Tenho acompanhado a discussão sobre regras no banco. As opiniões sobre regras 
no banco melhorar a performance vai em contrapartida a flexibilidade na mudança 
de um determinado RDBMS por outro, são até validas.
Temos um histórico ao longo desses anos, COBOL, DEPLHI, JAVA, VB, .NET e etc, 

O que tento dizer é que para as consultorias e suas fabricas é interessante ter 
um ERP e fazer com que este ERP seja vendido para clientes diferenciados e cada 
cliente ter o RDBMS desejado, o peixe que foi vendido e comprado pelas 
consultorias é a que rege o mercado, sendo assim a opinião do técnico fica em 
segundo plano.

Atenciosamente, 
André Luiz R. Marques 
Administrador de Banco de Dados - SQL Server/OracleTel: (21) 99978-4564 Evite 
imprimir. Colabore com o Meio Ambiente! "Embora ninguém possa voltar atrás e 
fazer um novo começo, qualquer um pode
começar agora e fazer um novo fim."    Chico Xavier

 

Em Terça-feira, 5 de Abril de 2016 10:46, "jlchia...@yahoo.com.br 
[oracle_br]"  escreveu:
 

     É, mas eu penso assim : com certeza, ao se usar em profundidade os 
recursos nativos de um RDBMS é verdadeiro que vc cria alguma "dependência" 
dele, vc em certo nível fica "amarrado" a esse RDBMS, mas é Óbvio que se vc 
'desapega'do database vc investe esforço na tool de desenvolvimento, 
centralizando regras e procedimentos/lógica/código que manipula dados e 
integridades nela... ALGUMA amarração vc TEM que ter, né não ? Absolutamente 
nÃO EXISTE um meio de vc não depender de alguma coisa...
  Então, sejamos práticos : nos últimos 5 anos, quantas vezes a sua Empresa 
teve que trocar de RDBMS ??? Nesse mesmo período, quantas vezes ela teve que 
trocar de plataforma de desenvolvimento ?? O que é mais estável portanto, 
confiar em continuidade do RDBMS ou da tool/solução de desenvolvimento ??
  
  Outro ponto, até que nível essa "dependência/amarração" com um fornecedor de 
RDBMS é verdadeira ??? Será que hoje em dia é TÃO impossível assim, tão 
mega-hiper-difícil vc traduzir/adaptar código SQL e PL/SQL e features de banco 
de um produto para outro, SE e QUANDO for necessário ? Sim, sabemos que 
principalmente nas features nem tudo o que existe num produto/num RDBMS existe 
em outro, mas que há muita similaridade há sim... Não é automático e simples 
traduzir/adaptar SE e QUANDo for necessário, mas imho é possível, sim, então  
NÃO VEJO como algo tão sério e crítico e limitante a eventual "DEPENDÊNCIA" de 
um RDBMS, não...
  
  []s
  
    Chiappa  #yiv9822278845 #yiv9822278845 -- #yiv9822278845ygrp-mkp 
{border:1px solid #d8d8d8;font-family:Arial;margin:10px 0;padding:0 
10px;}#yiv9822278845 #yiv9822278845ygrp-mkp hr {border:1px solid 
#d8d8d8;}#yiv9822278845 #yiv9822278845ygrp-mkp #yiv9822278845hd 
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px 
0;}#yiv9822278845 #yiv9822278845ygrp-mkp #yiv9822278845ads 
{margin-bottom:10px;}#yiv9822278845 #yiv9822278845ygrp-mkp .yiv9822278845ad 
{padding:0 0;}#yiv9822278845 #yiv9822278845ygrp-mkp .yiv9822278845ad p 
{margin:0;}#yiv9822278845 #yiv9822278845ygrp-mkp .yiv9822278845ad a 
{color:#ff;text-decoration:none;}#yiv9822278845 #yiv9822278845ygrp-sponsor 
#yiv9822278845ygrp-lc {font-family:Arial;}#yiv9822278845 
#yiv9822278845ygrp-sponsor #yiv9822278845ygrp-lc #yiv9822278845hd {margin:10px 
0px;font-weight:700;font-size:78%;line-height:122%;}#yiv9822278845 
#yiv9822278845ygrp-sponsor #yiv9822278845ygrp-lc .yiv9822278845ad 
{margin-bottom:10px;padding:0 0;}#yiv9822278845 #yiv9822278845actions 
{font-family:Verdana;font-size:11px;padding:10px 0;}#yiv9822278845 
#yiv9822278845activity 
{background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv9822278845
 #yiv9822278845activity span {font-weight:700;}#yiv9822278845 
#yiv9822278845activity span:first-child 
{text-transform:uppercase;}#yiv9822278845 #yiv9822278845activity span a 
{color:#5085b6;text-decoration:none;}#yiv9822278845 #yiv9822278845activity span 
span {color:#ff7900;}#yiv9822278845 #yiv9822278845activity span 
.yiv9822278845underline {text-decoration:underline;}#yiv9822278845 
.yiv9822278845attach 
{clear:both;display:table;font-family:Arial;font-size:12px;padding:10px 
0;width:400px;}#yiv9822278845 .yiv9822278845attach div a 
{text-decoration:none;}#yiv9822278845 .yiv9822278845attach img 
{border:none;padding-right:5px;}#yiv9822278845 .yiv9822278845attach label 
{display:block;margin-bottom:5px;}#yiv9822278845 .yiv9822278845attach label a 
{text-decoration:none;}#yiv9822278845 blockquote {margin:0 0 0 
4px;}#yiv9822278845 .yiv9822278845bold 
{font-family:Arial;font-size:13px;font-weight:700;}#yiv9822278845 
.yiv9822278845bold a {text-decoration:none;}#yiv9822278845 dd.yiv9822278845last 
p a {font-family:Verdana;font-weight:700;}#yiv9822278845 dd.yiv9822278845last p 
span {margin-right:10px;font-family:Verdana;font-weight:700;}#yiv9822278845 
dd.yiv9822278845last p span.yiv9822278845yshortcuts

Re: [oracle_br] RE: [oracl e_br] Regr a de negoc io na apli cação ou n o banco de dados?

2016-04-05 Por tôpico Fabio Prado fbifa...@gmail.com [oracle_br] 
Pessoal, se a prioridade é performance, opte pelas regras de negócio dentro
do BD. Falo disso no artigo:
http://www.fabioprado.net/2011/09/otimizando-performance-de-aplicacoes.html,
que tem inclusive um exemplo para qq um baixar e testar.

[]s



Sent with MailTrack


*Fábio Prado*

www.fabioprado.net
"Compartilhando conhecimentos e treinando profissionais em Bancos de Dados
Oracle"


Em 5 de abril de 2016 11:28, jlchia...@yahoo.com.br [oracle_br] <
oracle_br@yahoogrupos.com.br> escreveu:

>
>
> Pois é, ERPs são osso duro de roer : outro dia mesmo, atuando como
> especialista em tecnologia de bancos de dados num cliente da minha
> Consultoria (que foca em SAP), caí numa situação em que se tivessem sido
> usados alguns recursos do RDBMS Oracle (principalmente Particionamento e
> INSERT em direct-mode) determinada rotina de processamento seria completada
> em (por baixo) 10x menos tempo (isso COMPROVADO por POCs feitas), mas o
> fornecedor fechou questão em absoluto rejeitando a hipótese, justamente com
> o argumento de "dificuldade" de implementar (o que é uma piada, neguim
> investe um montão em tecnologias complexas como java e não quer investir em
> coisas simples como SQL e PL/SQL - pelamordedeus, SQL tem uma dúzia de
> comandos, PL/SQL duas, nem se compara com o tech stack exigido por outras
> coisas) , "quebra" do paradigma de universalidade/independência de
> databases por eles exigido Não teve jeito, eles desprezaram a Evidência
> real colhida e mandaram o cliente "aumentar o hardware" e é isso...
>
>  []s
>
>Chiappa
> 
>

Re: [oracle_br] RE: [oracl e_br] Regr a de negoc io na apli cação ou n o banco de dados?

2016-04-05 Por tôpico jlchia...@yahoo.com.br [oracle_br] 
Pois é, ERPs são osso duro de roer : outro dia mesmo, atuando como especialista 
em tecnologia de bancos de dados num cliente da minha Consultoria (que foca em 
SAP), caí numa situação em que se tivessem sido usados alguns recursos do RDBMS 
Oracle (principalmente Particionamento e INSERT em direct-mode) determinada 
rotina de processamento seria completada em (por baixo) 10x menos tempo (isso 
COMPROVADO por POCs feitas), mas o fornecedor fechou questão em absoluto 
rejeitando a hipótese, justamente com o argumento de "dificuldade" de 
implementar (o que é uma piada, neguim investe um montão em tecnologias 
complexas como java e não quer investir em coisas simples como SQL e PL/SQL - 
pelamordedeus, SQL tem uma dúzia de comandos, PL/SQL duas, nem se compara com o 
tech stack exigido por outras coisas) , "quebra" do paradigma de 
universalidade/independência de databases por eles exigido Não teve jeito, 
eles desprezaram a Evidência real colhida e mandaram o cliente "aumentar o 
hardware" e é isso...

 []s
 
   Chiappa

Re: [oracle_br] RE: [oracl e_br] Regr a de negoc io na apli cação ou n o banco de dados?

2016-04-05 Por tôpico angelo angelolis...@gmail.com [oracle_br] 
Essas empresas que comercializam ERP  ( Starsoft, Totvs e outros) gostam
muito desse pouco acoplamento do Banco de dados com a aplicacao, porque
fica mais facil para implantar
O SAP possui webservices pra integracao.

Diga-se de passagem, o Totvs ( Microsiga e cia ) o mesmo exe do servidor de
aplicacao é capaz de rodar com Oracle, Mysql e Sql server.. e até com
Postgresql rola.. Me corrijam se eu tiver errado.

Mas no caso do webservice, a regra de negocio ficaria nela. Só teria que
adaptar ela a outro ambiente BD fica tudo confinado na camada de acesso a
dados, nao precisando mexer no front-end, fica transparente para o
programador inclusive.





2016-04-05 10:46 GMT-03:00 jlchia...@yahoo.com.br [oracle_br] <
oracle_br@yahoogrupos.com.br>:

>
>
> É, mas eu penso assim : com certeza, ao se usar em profundidade os
> recursos nativos de um RDBMS é verdadeiro que vc cria alguma "dependência"
> dele, vc em certo nível fica "amarrado" a esse RDBMS, mas é Óbvio que se vc
> 'desapega'do database vc investe esforço na tool de desenvolvimento,
> centralizando regras e procedimentos/lógica/código que manipula dados e
> integridades nela... ALGUMA amarração vc TEM que ter, né não ?
> Absolutamente nÃO EXISTE um meio de vc não depender de alguma coisa...
>   Então, sejamos práticos : nos últimos 5 anos, quantas vezes a sua
> Empresa teve que trocar de RDBMS ??? Nesse mesmo período, quantas vezes ela
> teve que trocar de plataforma de desenvolvimento ?? O que é mais estável
> portanto, confiar em continuidade do RDBMS ou da tool/solução de
> desenvolvimento ??
>
>   Outro ponto, até que nível essa "dependência/amarração" com um
> fornecedor de RDBMS é verdadeira ??? Será que hoje em dia é TÃO impossível
> assim, tão mega-hiper-difícil vc traduzir/adaptar código SQL e PL/SQL e
> features de banco de um produto para outro, SE e QUANDO for necessário ?
> Sim, sabemos que principalmente nas features nem tudo o que existe num
> produto/num RDBMS existe em outro, mas que há muita similaridade há sim...
> Não é automático e simples traduzir/adaptar SE e QUANDo for necessário, mas
> imho é possível, sim, então  NÃO VEJO como algo tão sério e crítico e
> limitante a eventual "DEPENDÊNCIA" de um RDBMS, não...
>
>   []s
>
> Chiappa
> 
>