[firebase-br] aplicaçoes multi-banco...

[eduardo]

Oi Luis

> usuario de repente ficar milhonario e querer usar o Oracle (eu acredito que
> chegara um dia em que o FB nao ficara devendo muita coisa para o Oracle...

Atualmente, estou apostando todas as minhas fichas no FB. Mas...

O PostGree é free e está indo muito bem.
Algumas vezes também somos requisitados a fazer nosso sistema rodar 
debaixo de Oracle ou Sql Server em função do Cliente já ter a plataforma 
instalada e DBAs disponíveis. Claro que negamos, e pelo fato do FB ser 
free, ninguém resiste.

> mas ae ja eh outra historia...;o), e que, portanto, nao seria aconselhavel
> usar componentes de acesso que nos "prendam" ao Firebird, etc e talz, eu
> comecei a ter uma crise existencial diante dessa tendencia...

Esta crise não é privilégio seu. Tem muita gente preocupada com isso.

> o que me ocorreu eh que, segundo essa filosofia, a gente tambem nao devera
> usar recursos do Firebird, nem SQL, SP's ou Triggers, pois esses recursos
> sao especificos do Firebird e nao funcionarao no Oracle...

O que me preocupa mais é usar funções específicas de Componentes.
No tempo que trabalhava com Paradox e BDE, abusava de FindKey e 
SetRange, RecordCount, etc...
Tudo o que não existe ou não é prático em SGBDs.

Me lembrando daquele seus post anterior, fico pensando que amava o 
Clipper de paixão e ele foi-se, da mesma forma, só voava de TransBrasil 
e PAN-AM e tinha conta no Banco Nacional. Todos mortos.

A tendência de desenvolvimento também não é muito promissora para 
binários. .NET, JAVA e outros estão emergindo com muita força devido à 
necessidade de acesso remoto e multi-plataforma. Estas tendências é que 
nos deixam preocupados de como dimensionar nossos Sistemas e nos 
mantermos ágeis e competitivos no mercado.

O delphi, por sua vez, fica marcando passo para uma abordagem 
multi-plataforma - o Kilyx está sendo mantido por heróicos terceiros - e 
também não nos dá (Borland) quase nenhum suporte aos SGBDs emergentes.

Tudo isso é um inferno ! Preferia Clipper com DBF. Mas isso é só 
lamentação barata que não leva a nada.

Migrar de SGBD já não é muito fácil, migrar todo o código binário 
existente com funções que não são compatíveis com outros objetos, dá um 
trabalho danado. Já passei por isso.

> diante disso eu pergunto, entao, como eu deverei proceder, ja que nao devo
> fazer nada no banco? como eu deverei desenvolver as minhas aplicaçoes para
> que elas fiquem mais facilmente portaveis para outro banco que nao o
> Firebird???

O que acho fantástico no FB é a vontade dos desenvolvedores do projeto 
de se adequar ao máximo aos "Standards". Isso facilita(rá) bastante para 
portarmos nossos Scripts para outros bancos, se necessário.

> sera que eu deverei desenvolver algo tipow dessa maneira ae abaixo?
> 
> Table1.Edit;
> Table1.FieldByName( 'campo' ).AsString := Edit1.Text;
> Table1.Post;

Não exatamente assim, mas isolar, ao máximo, os acessos ao Banco com 
funções centralizadas e específicas e utilizar CDSs no Cliente podem 
facilitar bastante a migração se for necessária, mesmo para outra 
plataforma de desenvolvimento que possua objetos semelhantes (Lázarus, 
por ex.)

É um porre ter que ficar em cima do muro, mas enquanto não estiver me 
prejudicando, vou com o BEN-JOR: Prudência e caldo de galinha não faz 
mal a ninguém

> uma boa semana de trabalho a todos...

Para você também. Acho este tipo de discussão bastante proveitosa neste 
momento.

[]s Eduardo