[firebase-br] Polemica construtiva

Renato André renato em keninfo.com.br
Sex Maio 15 16:33:21 -03 2009


Obrigado,

Entendi... de todas as respostas que obtive no decorrer do dia na lista, 
acho que o resultado para esta indagação é ponderar o que será mais 
importante, uma otimização de tráfego de dados (caso de incluir rotinas de 
procedimentos e funções dentro do próprio banco) ou optar por criar um 
sistema independente de banco e consequentemente deixar o tráfego de rede um 
pouco maior. Bom, acho que é isso. Acho que essa é a resposta para a 
pergunta, ponderar o que será melhor no caso concreto, agradeço a todos as 
respostas enviadas.

Obrigado,
Renato  André.

----- Original Message ----- 
From: "Junior" <juniorvjl em gmail.com>
To: "FireBase" <lista em firebase.com.br>
Sent: Friday, May 15, 2009 4:16 PM
Subject: Re: [firebase-br] Polemica construtiva


Oi Renato André.

Acho que o caso para colocar rotinas dentro do banco geralmente é pensada
como solução para obter melhor desempenho das solicitações ao banco e
diminuição do tráfego de rede, principalmente, mais em aplicações simples e
de baixo volume de dados realmente não se tem grande diferenças e ai tambem
vejo que é mais simples colocar dentro do sistema executável...

Abrax brother
...

2009/5/15 Junior <juniorvjl em gmail.com>

> Salve pessoas...
>
> Conheço bem o protheus da totvs o qual estão citando como mutibanco, no
> entanto vejo que isso é mais uma jogada de marketing e $$ e em alguns 
> casos
> exigencias de grandes empresas sim..., conheço empresas que exigiram que o
> protheus fosse instalado em DB2 ( um dos banco de dados suportados pelo
> protheus ), mais acontece que como tudo existe um outro lado...
> Para que o protheus possa trabalhar com diversos banco de dados ele teve
> que usar uma ferramenta adicional que chama TOP CONNECT, então o PROTHEUS 
> se
> conecta com o TOP CONNECT e este por sua vez conversa com o driver ODBC da
> maquina que por sua vez manda a solicitação para o banco de dados. Vejam 
> que
> é maravilhoso poder escrever aplicativos para um monte de banco de dados 
> de
> uma vez mas por outro lado é horrendo ver como o desempenho é derrubado. A
> Totvs acabou fazendo isso um pouco por necessidade tambem, necessidade de
> evolução tecnologica, quem conhece a história de evolução dos sistemas 
> sabem
> do que estou falando.
> Para poder ter um sistema que fosse multibanco deveriamos ter q ter outras
> camadas para tratar as diversas particularidades de cada banco e no final
> das contas... pra quê? não vejo nenhum motivo realmente válido para isto.
>
> Esta é simplesmente minha opinião, abrax....
>
> 2009/5/15 Eduardo Pelizzari de Andrade <eduardoandrade em persoft.com.br>
>
> Oi Armando.
>>
>> O que você apresenta é a realidade da maioria das aplicações. Mas ser
>> muitlbanco pode ser uma característica importante para um sistema, seja 
>> pela
>> estratégia de marketiung ou por questões tecnológicas, ambos em casos
>> específicos. Como coloquei em outro post, ser bom ou legal é diferente de
>> ser necessário, mas se for uma necessidade você tem que implementar, isto
>> tem que ser pensado no estudo inicial do projeto. Um contra-exemplo está 
>> na
>> própria TOTVS, que apesar do RM ter desistido de ser multibanco, o 
>> Microsiga
>> que também é TOTVS continua tendo versões de DBF a Oracle, passando por 
>> SQL
>> Server. O que provavelmente aconteceu é que em um determinado momento, o
>> número de usuários RM na Oracle não justificava continuar com o
>> investimento.
>>
>> Eduardo Pelizzari de Andrade
>> Persoft Softwares Aplicativos
>>
>>
>>
>>
>> Armando Boza Gonçalves escreveu:
>>
>>>  A um tempo atrás quiseram implantar na minha cabeça essa "coisa" de
>>> multibanco, achei que eu estava fora dos "padrões" que utilizam hoje, me
>>> desesperei e comecei a estudar o assunto, e conforme fui pesquisando fui
>>> vendo que na verdade é meio ilusão isso. Nunca nenhum cliente meu exigiu 
>>> que
>>> meu sistema usa-se determinado banco de dados, e nunca um cliente meu 
>>> que ja
>>> usa o sistema pediu pra trocar também.
>>> Resumindo desisti do assunto :-)
>>>
>>> Agora só pra constar, acho que a maioria aqui conhece a RM Sistemas, que
>>> hoje é da TOTVS.
>>> O sistema da RM também se dizia multibanco (SQLServer ou Oracle), mas de
>>> acordo com um amigo meu que é usuário do sistema deles, eles abandonaram 
>>> o
>>> Oracle, pois estavam tendo muito problema com a programação.
>>> Agora pense, se a RM (TOTVS) que é gigantesca ($$), não usa mais
>>> multibanco, pq nós teríamos que usar?
>>>
>>> Isso é uma opinião minha viu pessoal, se alguem por acaso se ofender com
>>> algo ja peço desculpas antecipadamente.
>>>
>>>
>>> Att
>>>
>>> Armando
>>>
>>> ______________________________________________
>>> FireBase-BR (www.firebase.com.br) - Hospedado em www.locador.com.br
>>> Para saber como gerenciar/excluir seu cadastro na lista, use:
>>> http://www.firebase.com.br/fb/artigo.php?id=1107
>>> Para consultar mensagens antigas: http://firebase.com.br/pesquisa
>>>
>>> ------------------------------------------------------------------------
>>>
>>>
>>> No virus found in this incoming message.
>>> Checked by AVG - www.avg.com Version: 8.5.325 / Virus Database:
>>> 270.12.31/2116 - Release Date: 05/15/09 06:16:00
>>>
>>>
>>>
>>
>> ______________________________________________
>> FireBase-BR (www.firebase.com.br) - Hospedado em www.locador.com.br
>> Para saber como gerenciar/excluir seu cadastro na lista, use:
>> http://www.firebase.com.br/fb/artigo.php?id=1107
>> Para consultar mensagens antigas: http://firebase.com.br/pesquisa
>>
>
>
______________________________________________
FireBase-BR (www.firebase.com.br) - Hospedado em www.locador.com.br
Para saber como gerenciar/excluir seu cadastro na lista, use: 
http://www.firebase.com.br/fb/artigo.php?id=1107
Para consultar mensagens antigas: http://firebase.com.br/pesquisa





Mais detalhes sobre a lista de discussão lista