[firebase-br] CONEXAO DE DELPHI COM FIREBIRD, QUAL O MELHOR ?

[Fausto]

Amigo Almir..

Vejo em vc uma boa intensão em aprender a utilizar o FB da melhor forma 
possível, mas creio que para muitas de suas dúvidas vc vai ter que quebrar a 
cabeça um pouco, pois fica difícil dizer que este componente é melhor ou 
mais rápido.
Sugiro que vc comece a desenvolver algo, ai dependendo de sua necessidade vc 
vai achar o componente/tecnologia que melhor se adpte ao seu negócio.
Sugiro também que vc comece ler alguma coisa a respeito, no site da firebase 
tem muitos artigos interessantes e vc também pode pesquisar nas mensagens 
antigas da lista neste endereço: http://firebase.com.br/pesquisa.

Fausto
----- Original Message ----- 
From: "Almir" <almir74 em gmx.net>
To: "FireBase" <lista em firebase.com.br>; <jeandeadlucky em yahoo.com.br>
Sent: Wednesday, July 20, 2005 8:06 AM
Subject: Re: [firebase-br] CONEXAO DE DELPHI COM FIREBIRD, QUAL O MELHOR ?


*Amigo Francisco Tiago

Realmentre Inumeras vezes foram ditas, mas eu nao devia estar presente
nesta hora, entao me desculpe por perguntar novamente :)

1* -  Quando você diz que Multicamadas é complicado e que deixaria as
regras de negocio na aplicação, vc quer dizer que farias as triggers,
procedures, generatos e etc ! no front end ou seja no front end ?????
Realmente se eu usar o Dbexpress ou ZeosdBdo eu terei um componente
compativel com qualquer banco de dados! ai é so mudar o banco que ja
muda troda a conexa! mas e em relação as triggers, procedures  e a parte
que fica programada no banco de dados ?
Realmente acho melhor ter a possibilidade de mudar de banco, mas junto
com esta possibilidade tem de haver a possibilidade de mudar a parte
programada do SGBD junto !!! E é justamente ai que esá o problema!
Imagina reconstruir todas as triggers, views, domaisn, Roles, procedures
e etc  Novamente ???

2* - Como eu faço para utilizar o ClientDataset   como cache e na camada
de apresentação de dados ???

Grato
Almir Fiorio*

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


Boa tarde.

Esta é a vez nº 3401545348 que assuntos como esse acontecem na lista.
Temos um vasto histórico de lutas dignas de levarem o título de
"cruzadas"... Enfim, não aprendi a lição e vou meter o meu bedelho
novamente.

Antes de tudo, quero dizer que não conheço o IBO, não conheço o MDO e
que já trabalhei com o IBX. Estou "casado" hoje com o DBExpress que, na
minha opinião é o melhor componente custo x benefício que existe.

Primeiro: Ele é unidirecional. Isso é bom porque você nunca (a não ser
que o faça de propósito) vai guardar as informações em cache no
servidor, economizando memória... Caso um servidor esteja
sobrecarregado, você pode direcionar o acesso para outro servidor,
balanceando assim os teus processos.

Tá, Multicamadas é complicado, mas você não precisa utilizar a teoria
como ela é pregada.. pode dividir as regras de negócio entre o Servidor
de Aplicação e o Banco de dados. (Eu não faria isso, deixaria o possível
na aplicação)

Ele é compatível com qualquer banco que tenha um driver de acesso. Logo,
todos os bancos de dados (coisas como o access não entram nesta roda)
seriam conectáveis aos seus componentes, e sem muito trauma.

Porque você mudaria de banco?
O servidor não dá suporte ao teu banco; Você foi contratado para
trabalhar em outra empresa (que não trabalha com o Firebird); o teu
cliente já tem um banco de dados e quer o seu programa rodando com o que
já tem (oracle, MSSQLServer....); O teu cliente simplesmente quer...
Enfim... Eu acho mais fácil você mudar de banco de dados que de linguagem.

Porque DBXpress?
Você vai ter um leque maior de opções quando for escolher o banco de
dados. Não estou falando que amanhã você vá escolher outro banco de
dados.. ou que o Firebird não vai dar conta... Estou dizendo que outras
condições te obriguem a escolher outro banco... E a sua aplicação (e
você) deve estar pronta para isso

Porque Multicamadas?
Você vai escrever o acesso ao banco apenas uma vez. Caso o teu cliente
queira uma interface desktop, você não vai precisar reescrever nada (ou
quase nada)... E pode chamar tudo via WebServices... :D

Se em todo caso você escolher um acesso nativo...

Dê preferência a componentes que permitam acesso unidirecional ao banco
e utilize o ClientDataSet (tava demorando né?) como cache e na camada de
apresentação de dados. O importante é você estar sempre pronto para a
mudança... que é a única constante na informática.

[]'s

Francisco Thiago de Almeida
Enter&Plug Sistemas
Divisão: Desenvolvimento / Banco de dados
Franca - SP


______________________________________________
FireBase-BR (www.firebase.com.br) - Hospedado em www.bavs.com.br
Para editar sua configuração na lista, use o endereço 
http://mail.firebase.com.br/mailman/listinfo/lista_firebase.com.br
Para consultar mensagens antigas: http://firebase.com.br/pesquisa


-- 
No virus found in this incoming message.
Checked by AVG Anti-Virus.
Version: 7.0.323 / Virus Database: 267.9.2/52 - Release Date: 19/07/2005