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

Qua Jul 20 09:41:38 -03 2005

Olá Almir!
Tudo bem?

>Realmentre Inumeras vezes foram ditas, mas eu nao devia estar presente 
>nesta hora, entao me desculpe por perguntar novamente :)
Não tem pq se desculpar... isso - repetir tópicos - sempre acontece na 
lista... e acho que deve acontecer.... Mas esse aqui repete muito e é 
bastante polêmico!

>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 ?????

Não e sim. No caso específico de Multicamadas, você iria desenvolver duas 
aplicações distintas: Cliente e Servidor de aplicação... onde o cliente 
seria a interface com o usuário e o Servidor de aplicação seria o acesso ao 
banco de dados junto com as regras de negócio da aplicação. Quanto as 
trigger e procedures... bem... vou lhe passar a minha experiência 
particular: Eu escrevi um sistema que estava misto... Tinha algumas regras 
no servidor de aplicação e outras no banco de dados... Como você pode 
imaginar, virou uma bagunça. Estou partindo agora para um outro 
pensamento... Vou deixar o máximo de regras possíveis na aplicação, 
trabalhando com uma programação, que eu poderia chamar de "semi orientada a 
objetos".... É que eu não escrevo as classes.... mas ainda assim, tenho uma 
Unit para cada tabela com todas as regras referentes... E para o banco, 
sobra as validações em geral.... alguns processos que precisam ser 
otimizados.... Views... enfim, diferente do que se prega (onde TUDO deve 
ficar no servidor de aplicação, e o banco apenas um repositório de dados), 
estou fazendo do banco um "repositório inteligente".

>>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 ?
O que você programar no banco de dados deverá ser reescrito, se possível, no 
novo banco. Não acredito que você não consiga fazer isso, mas deverá 
conhecer bem onde está pisando, ou melhor, escrevendo, para não perder mais 
tempo corrigindo bugs e "tunandos" suas sp's e triggers.

>>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 ???

Por isso sugiro o Multicamadas, onde você não téra muito o que reescrever... 
quanto a views, domains e alguns outros objetos do banco...
Sua criação segue o padrão SQL... Logo, copiar o DML desses objetos e 
executar no novo banco não seria problema

>>2* - Como eu faço para utilizar o ClientDataset   como cache e na camada 
>>de apresentação de dados ???
Olha, existem manuais espalhados pela internet toda. O Bruno Lichot, da 
ClubeDelphi, é um evangelista do ClientDataSet assim como o Guinther... O 
Bruno, na minha opinião, é muito mais pronto a ajudar que o Guinther.... 
Inclusive, ele tem até uma apostila sobre o assunto e que você pode usar 
para dar os primeiros passos.

Espero ter ajudado

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

----- Original Message ----- 
From: Almir
To: FireBase ; 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

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 

_______________________________________________________ 
Yahoo! Acesso Grátis - Internet rápida e grátis. 
Instale o discador agora! http://br.acesso.yahoo.com/