[firebase-br] Polemica construtiva

Sáb Maio 16 14:43:43 -03 2009

Uma coisa vocês tem que concordar comigo. A principal vantagem de não 
colocar as regras de negócio no banco acaba estando ligada a comodidade e 
facilidade. Então devo concluir o seguinte, regras de negócio no banco 
ocupam menos banda de rede, o processamento é mais rápido. Então você pode 
ABRIR MÃO desta vantagem para facilitar migrações futuras.

Posso ser quadrado, gostar de sofrer, mas trabalho com FIREBIRD e com os 
componentes nativos, e se algum dia eu quiser mudar de banco, embora não 
veja necessidade nenhuma por enquanto, vou procurar explorar o máximo do 
banco, nem que para isso eu fique um bom tempo desenvolvendo e o programa 
fique compatível somente com aquele banco.

Eu prefiro ter um sistema com um banco funcinando em carga máxima, do que 
ter um sistema funcionando com vários bancos mas sem explorar os recursos 
dos mesmos e ficar funcionando meia bomba.

----- Original Message ----- 
From: "Eduardo Carneiro" <eduardofreitascarneiro em gmail.com>
To: "FireBase" <lista em firebase.com.br>
Sent: Friday, May 15, 2009 8:58 PM
Subject: Re: [firebase-br] Polemica construtiva

Salve lista...

 - Trabalhei eu uma softhouse e o diretor é um entendido no assunto e dá
aulas em universidade e desenvolveu muitos sistemas "parrudos" e coisas
assim...
 - Por coincidência, conversamos recentemente sobre este assunto, e como a
empresa dele tem muitos softwares com orgãos públicos em todo o Brasil. e a
lei agora é: ECONOMIZAR, migrando para SO free e bancos idem, fica a
questão: Se o governo paga anualmente milhões em licenças e os novos
gestores determinam que os aplicativos deverão também migrar, como ficariam
as regras de negócio no banco? E se o "novo banco" free não suportar tais
rotinas, ou mesmo ter-mos de reescrevê-las "do zero"? Acho que questões como
tráfego de dados é importante, mas as redes locais são bastante largas para
aguentar o fluxo gerado. Se as questões envolverem acessos remotos,
aplicações web com servlet já implementam as regras de negócio. Neste caso,
além de multiplataforma (browser) podemos ter bancos free nas aplicações. No
casos das grandes organizações, licenças de servidores não é problema, mas
para os pequenos, isto às vezes inviabiliza a prórpia negociação do
software.
O que acham?

Abraços
Eduardo de Freitas carneiro

2009/5/15 Adriano Ferreira <aerreira68 em gmail.com>

> Salve Junior,
>
> Apenas corrigindo ou melhorando o entendimento com relação ao Protheus da
> Microsiga, neste caso que você cita a empresa não teve que usar uma
> "ferramenta adicional", o Top Connect pois ele é o coração do Protheus, 
> ele
> está presente em todos os ambientes Microsiga com banco de dados 
> relacional.
>  O Top é a camada intermediária que faz a comunicação entre as aplicações 
> e
> o banco de dados, seja ele qual for.  Trabalho como desenvolvedor numa
> revenda autorizada Microsiga e temos clientes com DB2, Oracle, SQL Server,
> CTree e até mesmo DBF, e tudo isso é suportado na boa pelo Protheus graças
> ao top connect.
>
> Também trabalho com Firebird em projetos menores, e concordo que o que
> puder ficar no banco melhor, mas rotinas mais complexas são muito mais
> fáceis de desenvolver via programação do que via SP no banco, e muitas 
> vezes
> o tempo é escasso, então a solução mais rápida para desenvolver 
> normalmente
> é a que optamos.
>
> Abraços,
> _
> Adriano Ferreira
>
> ----- Original Message -----
>
>  From: Junior
>  To: FireBase
>  Sent: Friday, May 15, 2009 4:14 PM
>  Subject: Re: [firebase-br] Polemica construtiva
>
>
>   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....
> ______________________________________________
> 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

--------------------------------------------------------------------------------

No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 8.0.238 / Virus Database: 270.12.31/2116 - Release Date: 05/15/09 
06:16:00