Interbase 6.0 ou Firebird 1.5

Colega,
[quote:58544333e1=´IPC$´]Dizem que o Interbase é mais rápido, porém a conexão é mais lenta. [/quote:58544333e1]
Falso. Comparações com o IB 6.0 open source... O desempenho do Firebird 1.5 é bem maior... a diferença, em bases grandes, chega a ser ´gritante´...

[quote:58544333e1=´IPC$´]Dizem que o Firebird será o substituto do Interbase e que o Interbase será descontinuado pela Borland. [/quote:58544333e1]
Se o IB vai ser descontinuado, eu não sei... mas o Firebird é um projeto independente e, apesar de ter se originado do código fonte do IB open source, não deve ser encarado como substitudo ou ´continuação´ do IB...

T+

Vinicius2k, gostei de suas explanações mas quanto à objetividade da pergunta foi = 0.
Não sei sua experiência quanto a banco de dados, mas mesmo assim gostaria de saber entre os dois qual o Sr escolheria?

Perdõe-me,
Pensei ter deixado claro minha escolha : Firebird 1.5, com certeza.

Em relação à experiência com o BD, usei IB 6 por bastante tempo e migrei para Firebird há algum tempo também... não voltaria a usar o IB 6 de forma alguma...

T+

Devido aos contatos com alguns professores oficiais Borland e tb com alguns representantes eu dúvido muito que o Interbase seja descontinuado. Pelo contrário, acredito que estarão sempre investindo nesta ferramente. Outro ponto que acredito que não descontinuarão é a insistência e as ofertas que tenho recebido aqui na empresa para adiquirir este produto.

Hoje eu utilizo o Firebird 1.5 e estou plenamente satisfeito.

Gostaria de saber sua opinião também.

Volta e meia esta questao volta a tona.
INTERBASE: Pago,Proprietario.
Firebird: OpenSource, Desenvolvimento mais dinamico, ou seja, Bom, Bonito e barato, digo de GRACA.

Minha escolha: Firebird
mais precisamente: Firebird 1.5.

Pessoal, fiz alguns testes com uma tabela de ceps 80.000 regs, utilizando leitura sequencial para exportação em texto e vice-versa.
No vice-versa (lê texto e insere na tabela), o Firebird foi muito mais [b:d63c8bee74]lento[/b:d63c8bee74] que o interbase.
No acesso randômico, os dois bancos fora praticamente iguais.

Outra coisa que acho um pouco relevante é:
O Interbase tem um nome profissional (Borland)
E o Firebird ?

Olha,... não há o q escolher entre o IB6.0 e o FB (no meu entendimento)

-- a partir do momento q foi optado por uma solução Open Source a escolha (de longo prazo) é clara:: FIREBIRD

-- quanto a NOME, o FB é derivado do mesmo código da Borland, sendo assim possui o nome dela não é?!

Só faria sentido essa discussào (na minha opnião) se fosse entre o FB1.5 e o IB 7.1 -- que ai sim são produtos diferentes, e cada um com suas vantágens e mercado próprios.



T+

Para mim ainda não está nada claro.

Acho que não. Por exemplo, a Borland não irá lançar um Service Pack para o Firebird.


E numa importação de 80.000 registros em que Firebird processou 20x mais lento que o Interbase?
Será que foi o Delphi que puxou a sardinha p/ o Interbase?
Utilizei BDE com driver nativo p/ Interbase e driver ODBC p/ Firebird.

[quote:b7ab19bf32=´IPC$´]Utilizei BDE com driver nativo p/ Interbase e [b:b7ab19bf32]driver ODBC p/ Firebird[/b:b7ab19bf32].[/quote:b7ab19bf32]

Esta é a explicação da lentidão... Qualquer acesso via ODBC é muito, mas muito, mais lento que acesso nativo ou BDE... não faz sentido comparar desempenho usando formas de acesso diferentes.
Sugiro que vc refaça o teste usando a mesma conexão para ambos... não sei lhe dizer se o driver da BDE é 100¬ compatível com o FB, mas usando IBX ou dbExpress para os dois vc perceberá a diferença do FB 1.5...

T+

[quote:488bec8892=´IPC$´]
Acho que não. Por exemplo, a Borland não irá lançar um Service Pack para o Firebird.
[/quote:488bec8892]

E do onde vc tirou a idéia q ela (Borland) vai lançar algum ´Service Pack´ para o Interbase 6.0 ??


[quote:488bec8892=´IPC$´]
E numa importação de 80.000 registros em que Firebird processou 20x mais lento que o Interbase?
Será que foi o Delphi que puxou a sardinha p/ o Interbase?
Utilizei BDE com driver nativo p/ Interbase e driver ODBC p/ Firebird.[/quote:488bec8892]

Além do q o Vinicius2K já explicou, um testes desses não mostra muita coisa e tem muitas outras variáveis q podem afetar este desempenho e vc não postou.

Quando fizer testes vc deve ter MÉTODO para não ter resultados falsos. E, sempre acompanhado dos resultados vc deve fornecer os parâmetros relevantes q utilizou.



T+

Bom, deixe eu me apresentar melhor.
Trabalho com Delphi desde a versão 4, há uns 5 anos, antes disso desenvolvia sistemas em Cobol há uns 11 anos, daí quando ninguém mais queria aquela tela a caracter que o Cobol produzia, passei a utilizar Delphi. Desde a versão 5, utilizava os bancos Oracle e MS Sql Server via BDE com seus respectivos drivers ODBC.
Na versão 6, que já estou há 2 anos, não mudei o método de acesso e a performance não caiu, ou seja, utilizo Delphi c/ BDE e os componentes TDatabase e TQuery.

A conexão é a mesma (BDE - TDatabase) para ambos. Como o Delphi não possui um driver nativo p/ Firebird, utilizo seu driver ODBC. Se for este o problema, então acho que o Firebird deveria melhorar seu driver ODBC, pois qualquer banco respeitável como Oracle ou MS Sql Server, possuem seu driver ODBC para ser utilizado [b:5df44946ae]amplamente[/b:5df44946ae].

Quanto a conexão IBX, nem testei, pois tive problemas em rede quando o servidor ficava numa máquina, o Interbase em outra e, a veiculação dos dados era feita via Sockets; a partir do segundo cliente acessando, não sei porque mas a conexão caía.

Quanto a conexão DBExpress, esta veio a partir do Delphi 6 e acho que por questões de compatibilidade, não deveria ser mencionada, pois quem vem do Delphi 4 e quiser continuar utilizando BDE no Delphi 6, terá que mudar todos seus projetos quanto à conexão e acesso aos dados por causa do Firebird?


Não tirei a idéia de lugar algum, até mesmo pq o Interbase 6 está estagnado. Sò quis demonstrar que Firebird não tem nada a ver com Borland. Pode ser até que a Borland lance um Interbase 6.x gratuito p/ competir com o Firebir 1.5

Caro colega não entendí muito bem o que vc quis dizer.
Esse tal MÉTODO que vc cita é o mesmo nos dois bancos, ou seja, o programa é o mesmo, utilizei BDE com TDatabase para conexão e TQuery para manipulação dos dados, o que mudou foi o nome do Alias criado no BDE Administrator que logicamente é um para Interbase e outro para Firebird.

|A conexão é a mesma (BDE - TDatabase) para ambos. Como o Delphi
|não possui um driver nativo p/ Firebird, utilizo seu driver ODBC.

Entenda:: A conexão NÃO É A MESMA -- conectar com BDE via um driver ´nativo´ e via ODBC definitivamente NÃO é a mesma coisa!

Vc poderia utilizar o mesmo Drive do Interbase com o FB.

No mais -- o modelo do BDE não é o melhor para SGBD além de seu suporte ter sido encerrado -- sendo assim, seria melhor se vc utilizase outra solução.


|Se for este o problema, então acho que o Firebird deveria melhorar seu
|driver ODBC, pois qualquer banco respeitável como Oracle ou MS Sql
|Server, possuem seu driver ODBC para ser utilizado amplamente.

O problema é q vc não tomou conhecimento (ainda) que conexões ODBC costumam sempre ser mais LENTAS que outras opções de conectividade! Isso ocorre para QUALQUER banco de dados e não é por isso q os bancos vão deixar de disponibilizar seus Drivers (ODBC é um meio padrão) ou quer dizer q os Drivers não funcionam... possuem apenas performance inferior.

Só para vc entender, a performance com ODBC é um pouco inferior por 2 motivos principais:: 1 - é uma interface padrão; 2 - é um intermediário.


|Quanto a conexão IBX, nem testei, pois tive problemas em rede quando
|o servidor ficava numa máquina, o Interbase em outra e, a veiculação
|dos dados era feita via Sockets; a partir do segundo cliente acessando,
|não sei porque mas a conexão caía.

Poste aqui seu problema q tenho certeza os usuários irão ajudar a resolver.


|terá que mudar todos seus projetos quanto à conexão e acesso aos
|dados por causa do Firebird?

Não por causa do FB -- se desejar melhorar sua aplicação para qualquer SGBD terá de passar por isso.


|Sò quis demonstrar que Firebird não tem nada a ver com Borland.

Não tem a ver, mas tem o código base dela. No caso do FB 1.0 é ´exatamente´ mesmo do IB 6.0


|Esse tal MÉTODO que vc cita é o mesmo nos dois bancos, ou seja, o
|programa é o mesmo, utilizei BDE com TDatabase para conexão e

Acho q já expliquei acima q as conexões são diferentes. Bom, quanto a método, quiz dizer que fazer testes não é apenas fazer muitos inserts e medir o tempo e postar...

Vc tem q configurar e informar as pessoas do ambiente q vc utilizou -- diversos parâmetros podem influir como o hardware, a versão do banco, configuração do SGBD, parâmetros do banco de dados, a CONECTIVIDADE, etc -- mas deixa isso pra lá! ;)



T+

Está bem, vou retestar com DBExpress, quanto aos problemas do IBX, o tópico é muito grande para ser explicado e acho que os colaboradores não teriam paciência para entendê-lo, pois o problema ocorre quando o servidor está na M1, o banco na M2 e os clientes na M1,M2...Mn.
Os clientes se conectam ao servidor por Socket(IP e porta), este conecta-se ao banco via IBX e atende aos clientes também via Socket. O problema ocorre só quando servidor e banco estão em máquinas separadas; na mesma máquina tudo funciona perfeitamente e o IBX é mais rápido que o BDE.

Obs: Vc poderia me dizer onde achar um driver DBExpress e os parâmetros de DBXConnections.ini e DBXDrivers.ini p/ Firebird?
Ou os do Interbase são os mesmos?
O LibraryName é dbexpint.dll e o VendorLib é GDS32.dll.

[quote:844ce8ebbf=´IPC$´]A conexão é a mesma (BDE - TDatabase) para ambos. Como o Delphi não possui um driver nativo p/ Firebird, utilizo seu driver ODBC. Se for este o problema, então acho que o Firebird deveria melhorar seu driver ODBC, pois qualquer banco respeitável como Oracle ou MS Sql Server, possuem seu driver ODBC para ser utilizado [b:844ce8ebbf]amplamente[/b:844ce8ebbf].[/quote:844ce8ebbf]
Apenas reforçando o que o afarias, já mencionou... A conexão não é a mesma... uma sequencia de ligação simplificada para que vc perceba a diferença:
Interbase : Servidor -> BDE -> Database
Firebird : Servidor -> ODBC -> BDE -> Database
Para o Firebird vc tem um intermediário entre a BDE e o Servidor que não existe para o Interbase.
Com relação aos métodos, não sou grande conhecedor dos mesmos, mas à minha maneira, consigo os resultados... a idéia básica é comparar bancos usando a mesma camada de acesso e funções particulares e comparar camadas de acesso usando o mesmo banco... é assim que eu faço (nada extremamente técnico)...
Eu não sabia q o driver da BDE para Interbase era compatível com o FB 1.5, mas já q o afarias forneceu essa informação, faça o teste com os dois servidores, sem mudar nada na aplicação...


Não sei se entendi bem... neste caso vc estava com uma aplicação em 3 camadas? se for, vc não é obrigado a utilizar 3 camadas por causa do IBX... vc pode continuar trabalhando normalmente, em duas camadas, aliás é assim que eu trabalho e, honestamente, não vejo grandes vantagens em 3 camadas para meu mercado (pequeno/médio)...


Bem, eu discordo de vc pq devemos acompanhar os avanços das tecnologias quando estes nos favorecem... se eu fosse me acomodar com o que ´funciona´, estaria desenvolvendo minhas aplicações em Clipper até hoje... continuar a usar a BDE hoje, perdõe-me a sinceridade, mas é estar ´um passo atras´...
Particularmente, já passei por muitas migrações, já que trabalho com Delphi desde a versão 2... Utilizei BDE+Paradox, BDE+Access, ADO+Access, IBX+Interbase, e atualmente uso dbExpress+Firebird e ADO+SQL Server... para mim o segredo está em programar pouco nos componentes e muitas funções e procedures para automatizar os processos... numa eventual migração, muda-se a classe de uma função e alguns métodos e pronto...

T+

[quote:f30400fc00=´IPC$´]Está bem, vou retestar com DBExpress, quanto aos problemas do IBX, o tópico é muito grande para ser explicado e acho que os colaboradores não teriam paciência para entendê-lo, pois o problema ocorre quando o servidor está na M1, o banco na M2 e os clientes na M1,M2...Mn.
Os clientes se conectam ao servidor por Socket(IP e porta), este conecta-se ao banco via IBX e atende aos clientes também via Socket. O problema ocorre só quando servidor e banco estão em máquinas separadas; na mesma máquina tudo funciona perfeitamente e o IBX é mais rápido que o BDE.[/quote:f30400fc00]
Posso até não poder lhe ajudar, mas esteja certo de que a exposição do seu problema na comunidade, não será em vão. No que estiver ao nosso alcance, conte conosco.


Por enquanto, como o Firebird foi baseado no Interbase, vc pode usar o mesmo driver (LibraryName), apenas a ´VendorLib´ deve ser alterada para ´fbclient.dll´...
Se desejar testar outro driver, este é free e, ao menos por enquanto, se comporta bem, em meus testes : http://www.progdigy.com/download/UIBDBExp12Win32.zip, sugiro que também o teste, caso migre para dbExpress, para prevenir alguma possível incompatibilidade de versões novas do Firebird com o driver nativo para IB...

T+

[quote:2f5f12f26f=´IPC$´]pois o problema ocorre quando o servidor está na M1, o banco na M2 e os clientes na M1,M2...Mn.
[/quote:2f5f12f26f]

Bom, a não ser q por ´servidor´ vc esteja falando o seu ´midle tier´´, o problema é simples! O INTERBASE *não* pode acessar uma base de dados q não esteja na mesma máquina q o servidor IB

Isso não é problema do IBX, é apenas a forma como o INTERBASE funciona.


[quote:2f5f12f26f=´IPC$´]Obs: Vc poderia me dizer onde achar um driver DBExpress e os parâmetros de DBXConnections.ini e DBXDrivers.ini p/ Firebird? [/quote:2f5f12f26f]

InterXpress para Firebird (Comercial):: http://www.upscene.com/


[quote:2f5f12f26f=´IPC$´]Ou os do Interbase são os mesmos?|O LibraryName é dbexpint.dll e o VendorLib é GDS32.dll[/quote:2f5f12f26f]

Pode ser tb! (como dito pelo Vinicius2k)

e sobre o driver BDE do IB ser compatível com Fb 1.5 -- eu nunca testei realmente -- apenas acho q funciona.


T+

A aplicação é em 3 camadas. Há quem não veja vantagens, mas eu vejo muitas.
1 - Imagine 20 IPs acessando o mesmo banco em 2 camadas. Fatalmente vc terá 20 conexões penduradas. Os bancos são vendidos por número de conexões e o Interbase gratuito só aceita até 5 simultaneas.
2 - Vc tem uma classe única de conexão, se o banco mudar, ou se o tipo de conexão mudar, vc somente altera essa classe.
3 - A forma de acesso e manipulação dos dados é padronizada na aplicação servidora e se houverem novas implementações, vc só mexe nesse programa.
4 - As aplicações clientes ficam livres dos componentes sql, pois elas não tem nada a ver com o banco de dados e sim com a aplicação servidora.

Quanto ao driver Interbase compatível com o Firebird, se for o driver nativo INTRBASE, no meu caso ele não reconheceu o Firebird, mas também não perdí muito tempo nisso e passei logo para o ODBC.

Quanto ao ADO, perdí uns 3 meses com testes nessa tecnologia e confesso que desistí pq utiliza automação OLE Variant e a performance caiu bastante em relação ao BDE.

|1 - Imagine 20 IPs acessando o mesmo banco em 2 camadas.
|Fatalmente vc terá 20 conexões penduradas. Os bancos são vendidos
|por número de conexões e o Interbase gratuito só aceita até 5
|simultaneas.

FALSO:: O Interbase 6.0 (gratúito) aceita 1024 conexões.

Além do mais, não importa se sua aplicação é 2 ou 3 camadas, as licenças dos bancos de dados são por USUÁRIOS (PESSOAS) e nào por conexões!


|2 - Vc tem uma classe única de conexão, se o banco mudar, ou se o tipo
|de conexão mudar, vc somente altera essa classe.

Se não me engano tb funciona assim com o DBX (em 2 camadas)


|3 - A forma de acesso e manipulação dos dados é padronizada na
|aplicação servidora e se houverem novas implementações, vc só mexe
|nesse programa.

+/- né?!



T+

Agora entendi seu problema com o IBX e realmente, pelo que sei, vc está limitado no que o afarias disse...
Bem, honestamente, não vejo vantagem em multi-tier, mas essa é só uma opinião pessoal... a idéia (teoria) é boa, mas para mim e meus tipos de aplicações, não funciona... há algum tempo desenvolvi um projeto com essa tecnologia, e por acabar tendo que manutenir constantemente sempre as duas aplicações, preferi transformá-lo em 2 camadas...

Só uma dica em relação ao número de conexões : o IB 6.0 Free não é o que acompanha (CD) o Delphi 6... os downloads:
Versão inicial, oficial da Borland, 6.0.1.0 :
http://info.borland.com/devsupport/interbase/opensource/
Ultima versão ´extra-oficial´ compilada pela MERS, 6.0.2.0 :
http://mers.com/ib_wi_os_tIB6_0_2_0.exe

Sobre o driver do BDE, note que, assim como o IBX, ele (o driver) está preso na GDS32.DLL, que no FB 1.5 mudou de nome para FBCLIENT.DLL, então vc, ao instalar o FB, deve efetuar uma cópia da FBCLIENT.DLL com o nome de GDS32.DLL, o próprio setup para Win32 lhe sugere isto... pode ser este o problema...

Sobre a classe única de conexão, em teoria, com dbExpress em 2 camadas também é assim, desde que vc não use funções proprietárias de um banco específico... digo em teoria, pq nunca precisei migrar de base e não tenho certeza dos resultados na prática...

T+

[quote=Vinicius2K]ele (o driver) está preso na GDS32.DLL, que no FB 1.5 mudou de nome para FBCLIENT.DLL, então vc, ao instalar o FB, deve efetuar uma cópia da FBCLIENT.DLL com o nome de GDS32.DLL,

Mas foi isso que eu quis dizer com ´... o próprio setup para Win32 lhe sugere isto´ :wink:

T+

Bom, parece que o assunto tendeu um pouquinho p/ multi-tier.
Atualmente trabalho com 3 bancos: SQL Server, Interbase e MySQL com conexões BDE, DBExpress e Interbase Express(IBX); ou seja o servidor está implementado para estes 3 bancos.
Se aparecer um cliente com outro banco, só tenho que implementar o objeto de conexão embutido no programa servidor.
Este objeto retorna as classes ancestrais TCustomConnection p/ conexão e TDataset p/ acesso aos dados, pois os 3 meios de acesso descritos acima, retornam sempre essas classes.
Os comandos necessários para cada meio de acesso, são feitos nesta classe de conexão.
Por exemplo: Se a aplicação cliente solicitar um cursor de dados atualizável e o acesso for BDE, a classe de conexão retorna ao servidor um TQuery c/ RequestLive=true. Se for DBExpress, retorna um TSQLClientDataset com seus eventos AfterPost e AfterDelete já implementados. Se for IBX, retorna um TIBClientDataset também com seus eventos p/ Post e ExecSql implementados.
A atribuição de parâmetros (ParamByName), também é implementada nesta classe, pois cada tipo de dado pode ter uma atribuição de parâmetro diferente p/ cada banco; um caso típico é o Date p/ um, Datetime p/ outro e no MySql uma string(aaaa/mm/dd).

Não sei o tipo de aplicações do Vinicius2K, até poderíamos trocar umas idéias pq não ví aplicação ainda que não pudesse ser desenvolvida em multi-camadas.

Quanto às classes proprietárias p/ cada banco, simplesmente não as utilizo. Triggers, Stored Procedures e Auto-Incremento, faço tudo via comandos SQL; com isto fica tudo transparente para cada banco.

Quanto às conexões dos bancos, mesmo que alguns sejam vendidos por número de usuários e os livres aceitem até 1024 conexões, a performance do banco não degrada na medida que se penduram mais conexões? Sem falar que a própria conexão em si já é lenta.

Outro ponto que acho relevante é que para alguns bancos, o cliente não consegue conexão via internet. Daí como vcs fariam em 2 camadas?

Foi muito difícil chegar às 3 camadas e atualmente será muito difícil alguém me convencer a voltar às 2 camadas. É praticamente uma ida sem volta. Não é só em termos de banco de dados, mas também vcs tem um servidor que se comunica com todos os clientes conectados. A partir daí, vcs podem fazer com que os próprios clientes se comuniquem entre si, como msgs, chats, transferência de arquivos, etc...
Por exemplo, a aplicação cliente, dentre as várias ferramentas, possui uma dll que pede ao servidor a lista de usuários conectados; essa lista aparece no cliente num listview; daí ele pode selecionar alguém e enviar alguma msg, blob, arquivo num simples click de um botão e o outro lado recebe alí na tela naquela hora sem importar onde esteja.

Bom, pessoal é isso aí, para mim até agora ví muitas vantagens nisso e as desvantagens por enquanto ainda são poucas.

[quote:861094af5a=´IPC$´]Não sei o tipo de aplicações do Vinicius2K, até poderíamos trocar umas idéias pq não ví aplicação ainda que não pudesse ser desenvolvida em multi-camadas.[/quote:861094af5a]
Não é que não possam.. com certeza podem, talvez um dos meus pontos fracos seja pouco conhecimento desta tecnologia...
De forma nenhuma afirmo entre 2 ou 3 camadas que uma seja melhor que outra... creio que tudo depende da situação, assim como o SGBD e a camada de acesso utilizada... tenho alguns pontos que me levam a não desenvolver em multi-tier atualmente, e depois de conhecê-los (os mais importantes), vc talvez até concorde comigo :

-> Minhas aplicações, tem, até hoje. um número máximo de 25 usuarios. Sendo que a grande maioria dos meus clientes tem entre 8 e 12 pontos. Normalmente usuários bem ´usuários´ mesmo... vc me entende não é mesmo?
-> Os O.S não colaboram muito com tecnologias novas (muitos clientes trabalham com várias estações Win95 e Servidores N.T 4)
-> Tenho alguns clientes com servidores Linux, logo COM+ sem chance... e como domino apenas o básico de Linux desconheço até mesmo alternativas a ela (COM)...
-> Alguns clientes (poucos) não tem servidor dedicado... o Servidor do banco é uma estação Win2000 Pro no C.P.D. ou num escritório da administração e manter uma aplicação midle-tier rodando nele (uma estação) pode ser ´dor de cabeça´...

Como vc pode perceber, existe uma grande variedade de perfis de clientes, então é complicado adotar uma tecnologia mais exigente... meu tempo de desenvolvimento cresceria muito pois eu perderia parte da padronização e de meu repositório, desenvolvendo soluções específicas para cada cliente...

Tenho clientes num perfil que tenho certeza que seria perfeita a utilização de midle-tier... Eles tem redes modernas e bem estruturadas (LANs e WANs), usuarios com nível mais avançado... trabalham com diversos tipos de conexão, inclusive remotas via Metraframe (citrix) e Terminal Services...
Mas estes clientes são meus em Web/Intranet, infelizmente eu não tive chances, ao menos por enquanto, de servi-los com aplicações em Delphi, visto que utilizam modernos ERPs, CRMs, Hyperion, etc...

O fato é que enquanto meu mercado for de pequeno/médio porte, e eu tiver sempre que ´brigar´ por preço... preciso de soluções eficazes e simples e que me façam ganhar tempo... multi-tier e até mesmo .net, não são realidades para mim no momento...

Espero que vc tenha entendido meu ponto de vista, que não é crítica à 3 camadas, apenas uma questão de escolha baseada na minha realidade de projetos...

T+

|Bom, parece que o assunto tendeu um pouquinho p/ multi-tier.

Foi?!


|Por exemplo: Se a aplicação cliente solicitar um cursor de dados
|atualizável e o acesso for BDE, a classe de conexão retorna ao servidor
|um TQuery c/ RequestLive=true. Se for DBExpress, {...}

Vc não trabalha com Providers e ClientDataSets?? Acho q deixa de ter algumas das grandes vantagens de 3 camadas... (com MIDAS)

1 exemplo é utilizar cursores bi-direcionais ´editáveis´ (como o ex. q deu do TQuery/DBE) que não são bons e nem são necessários se vc utiliza Providers.


|Se for IBX, retorna um TIBClientDataset também com seus eventos p/
|Post e ExecSql implementados.

Esse componente (TIBClientDataset) foi descontinuado (na verdade, na minha opnião não devia nem ter existido! :))

Sendo assim, acho q não deveria utilizá-lo


|a performance do banco não degrada na medida que se penduram mais
|conexões?

Bom, mas, se houver 4 clientes pendurados no servidor de aplicação não haverá 4 conexões no banco de qualquer forma?? Compartilhar a mesma conexão entre clientes pode ser ainda pior para performance.


|Sem falar que a própria conexão em si já é lenta.

Isso até é... dai a vantagem dos pools de conexão... (em 3 camadas)


|Outro ponto que acho relevante é que para alguns bancos, o cliente não
|consegue conexão via internet. Daí como vcs fariam em 2 camadas?

Acho q apenas gerenciadores de arquivo não permitem conexão por TCP -- ai nem vale a pena discutir.


|Foi muito difícil chegar às 3 camadas e atualmente será muito difícil
|alguém me convencer a voltar às 2 camadas. É praticamente uma ida
|sem volta.

hehehe... assim como o Vina tb não quiz ou quero q vc desista de 3 camadas -- cada caso é um caso -- eu particularmente trabalho na maior parte com sistemas em 2 camadas, mas tb trabalho com 3 camadas e acho uma boa arquitetura.



T+

Bom, vc deve estar pensando que sou expert em Com/DCom ou Corba ou Visibroker ou .Net ou Midas.
Nada disso, utilizo apenas Delphi, Sockets e Threads.
O servidor possui um TServerSocket e os clientes um TClientSocket e pronto; quando o cliente se conecta, o servidor abre um thread para ele, aguarda a informação de login/senha e depois se tudo ok, fica ´escutando´
pela porta alguma solicitação, senão, desconecta o cliente.
O envio dos dados é feito através de uma classe de transporte de dados via SendBuf e ReceiveBuf.
O sistema operacional não precisa ser um servidor, pode ser qualquer um pq não são utilizados os recursos de sistemas operacionais servidores; quem faz tudo é o Delphi, apenas digo ao cliente que é bom que o servidor esteja numa máquina NT ou XP por questões de travamento dos 9x.

Quanto a preço, um sistema desses tem um preço um pouco superior, pois envolve uma série de parâmetros que terão que ser explicados ao cliente; por ex: vc não pode mandar um cursor com 10.000 registros de uma só vez senão a rede ficará muito lenta; vc tem que parametrizar cada tabela a quantidade de registros que serão enviados para combos, grids, relatórios, assim como o tamanho de envio automático de Blolbs.
No lado cliente, vc tem que ter rotinas de leia mais, volte 100, vá p/ fim, vá p/ início, pesquisa, refresh etc...
Ou seja, no cliente vc não tem mais um DBGrid que controla automaticamente os registros da tabela, e sim um ListView ou coisa parecida e isso tudo vc tem que implementar via código.
É por isso que é mais caro, mas também no final o cliente acaba gostando.

Quanto ao Linux, por enquanto de minha parte ainda está esquecido.

Tambem achei o desempenho do FB 1.5(DbExpress, IBX e UIB) bem inferior ao MySQL(DBxpress) e o Access (ADO, Zeos) com uma tabela de apenas 1,4 Mb e 2526 registros (FB 15 s, MsSQL 4 seg, Access 5seg e 2seg cache)

Colega,

Isso depende de vários fatores. Por exemplo, alguns :
-> Capacidade de processamento do servidor (máquina)... vi em outro post que vc fez estes testes usando um Duron 950 (128kb cache L2) em Windows 9X, ou seja, um S.O ruim que não trabalha o Firebird como sendo um serviço e não permitindo definição de prioridade, num processador ruim, com um clock baixo para servidor, com o mínimo de cache, e como se trata de Duron, é provavel que esteja montado em uma das placas PCChips M..(alguma coisa)...
-> Quantidade de memória do servidor
-> Tamanho da página (PAGE SIZE) do banco de dados... quanto maior a página mais se ganha em performance, mas também mais memória é exigida do servidor...
Não há como falar em performance de um SGBD sem atrelá-la à ´máquina´ servidor..
-> Definição coerente de índices com as queries enviadas ao servidor e estudo de PLANs...

O MySQL é rápido, de fato, mas está longe de ser um SGBD... afinal, a única coisa que ele tem são tabelas e índices, como um banco Desktop... sem triggers, sem SPs, sem Integridade Referencial, logo, fica fácil ser rápido...

O Access nem deveria entrar nesta discussão, pq não é SGBD, é um banco de dados Desktop e todos os registros são transportados pela rede e trabalhandos na estação... logo o servidor não influi em nada a não ser na velocidade do disco rígido, afinal ele está sendo servidor de arquivos... os fatores são : velocidade da rede e capacidade de processamento e memória da estação.

Veja estes dois artigos... eles podem lhe ajudar a entender como funciona e, consequentemente, aumentar significativamente a sua performance...
http://www.firebase.com.br/cgi-bin/firebase.cgi/artigo?ID=126
http://www.firebase.com.br/cgi-bin/firebase.cgi/artigo?ID=222

T+

Desculpe-me Afarias, mas não ví sua mensagem.
Não trabalho com Providers e os ClientDataSets que utilizo são o TIBClientDataset p/ IBX e TSQLClientDataset p/ DBExpress; isso quando o cursor não for read-only ou bidirecional, se for read-only unidirecional ou p/ comandos ExecSql(Insert, Update e Delete), utilizo TIBQuery e TSQLQuery. Quanto ao TQuery do BDE ser bom ou não, isto eu não sei, porém ele atende muito bem ao SQL Server.
No caso do TIBQuery, apanhei um pouco com seu TIBTransaction que é diferente do BDE, pois ele abre uma transação p/ cada query independentemente de ser dado StartTransaciotn ou não e quando a query for reutilizada, seu IBTransaction tem que estar fechado.
Falando em TIBClientDataset, no caso de um cursor atualizável(TDataset.Post), qual componente IBX vc utilizaria?
O TIBQuery é um dataset read-only.

Quanto às conexões, se houverem 4 ou 40 clientes conectados ao servidor, serão 4 ou 40 threads de solicitações e tantos objetos TDatasets quantos forem necessãrios, mas a conexão ao banco de dados é uma só. Só são feitas conexões extras no caso de StartTransaction e Commit ou Rollback.

|Não trabalho com Providers e os ClientDataSets que utilizo são o
|TIBClientDataset p/ IBX e TSQLClientDataset p/ DBExpress; {...}

Percebi q vc tem uma implementação própia para 3-camadas (como citou na mensagem anterior) -- eu apenas sugiro um ´melhoramento´ que é a implementação ou uso de uma tabela de memória no cliente e apenas execução de comandos SQL (update/insert/delete) no servidor.

Assim são as em geral as tecnologias para 3-camadas e vc não tem q trabalhar com DataSets bi-direcionais (a não ser a tabela de memória no cliente) ou ´cursores editáveis´

|No caso do TIBQuery, apanhei um pouco com seu TIBTransaction que é
|diferente do BDE, pois ele abre uma transação p/ cada query
|independentemente de ser dado StartTransaciotn ou não

A arquitetura do Interbase exige uma transação mesmo q para seleção de registros. O BDE sempre trabalha essas transações implicitamente (o q na minha opnião não é legal!)


|e quando a query for reutilizada, seu IBTransaction tem que estar
|fechado.

Não -- vc pode alterar o SQL da query e re-executar na mesma transação


|O TIBQuery é um dataset read-only.

Mas é bi-direcional. Basta associar um IBUpdateSQL e ele passa a ser ´editável´. Ou vc pode usar um IbDataSet que é o mesmo q 1 IBQuery + 1 IBUpdateSQL


|Quanto às conexões, se houverem 4 ou 40 clientes conectados ao
|servidor, serão 4 ou 40 threads de solicitações e tantos objetos
|TDatasets quantos forem necessãrios, mas a conexão ao banco de
|dados é uma só. Só são feitas conexões extras no caso de
|StartTransaction e Commit ou Rollback.

Mas ai os dados são serializados na conexão o q pode oferecer grande perda de performance.

Neste caso eu sugiro a implamentação de um pool de conexão -- seu servidor poderia iniciar com umas 10 conexões realizadas (depende do número médio de clientes pendurados no servidor em geral) alternando entre clientes -- e solicitar mais conforme a necessidade... um componente q pode ajudar nisso é o IBConnectionBroker



T+

Mas é isso mesmo que ocorre; o cursor dos comandos Select é enviado ao cliente; não inteiro senão prejudica a performance da rede, mas conforme os parâmetros para cada tabela.
Agora pq eu não preciso de cursores bidirecionais?
Por ex, uma tabela que gera um cursor com 10.000 registros, na parametrização são mandados 200 em 200 p/ o cliente; e se ele quiser voltar os últimos 200?
Hoje o servidor faz isto na mesma query por bookmarks e o Dataset tem que ser bidirecional.

No meu caso não pq utilizo reaproveitamento de objetos e nunca sei se aquele TIBQuery vai ser utilizado novamente, por isso a cada Execsql eu tenho que dar o Commit no IBTransaction daquela query.

Só não entendí essa serialização dos dados que o banco faz com apenas uma conexão.

Estou achando este tópico muito interessante ! :wink:
IPC$, novamente, não é crítica, estou, de certa forma, impressionado com o que vc desenvolveu...

Mas com a midas (Provider no servidor de aplicação e ClientDataSet no cliente), vc consegue, facilmente, a parametrização do tamanho do pacote de dados... a propriedade ´PacketRecords´ do ClientDataSet controla qual o tamanho do pacote q será solicitado ao Provider... em duas camadas basta configurar ela e pronto, já nas 3 camadas é necessário trabalhar no BeforeGetRecords para informar ao Provider remoto a partir de qual registro realizar o fetch... Só não posso lhe afirmar qual dos dois seria mais rápido (midas ou a sua estrutura), mas é possível...

No meu ponto de vista, usar a midas, facilitaria seu trabalho e propiciaria uma maior facilidade de adaptação à Bancos diferentes e migração de tecnologias... além disso vc poderia, até mesmo, onde achar conveniente usar data-awares como DBGrids, por exemplo, sem nenhuma queda de performance...

T+

Pois é, com certeza se utilizasse aquilo que ja está pronto, não teria tido tanto trabalho para escrever tudo na unha.
O engraçado é que quando comecei com isso, não pretendia escrever um servidor de banco de dados. Comecei brincando com Sockets e Threads para fazer várias máquinas se comunicarem, daí começaram a surgir alguns problemas tais como: Como enviar uma estrutura de dados p/ o cliente. Pesquisei na internet e achei uma classe chamada RPCBuffer; daí achei interessante a forma como ela trabalha, ou seja, é como se fosse um cursor de dados em memória. Como era paga e não conseguia atualizar os dados já colocados, comecei a testar os comandos ReallocMem, FreeMem, Move e com isto conseguí escrever uma classe p/ manipulação e transporte de dados implementando um TCustomWinSocket em seu construtor para envio e leitura de dados.
E hoje é assim que funciona, pode ser complicado, mas com um simples PChar e os métodos SendBuf e ReceiveBuf, clientes e servidor se comunicam com qualquer tipo de dados.
Sinceramente, como já estou há 3 anos com isso, não tenho coragem para voltar atrás p/ modificar tudo p/ Providers, Midas ou outro tipo de tecnologia. Confio muito no básico do Delphi e coloco ele pra trabalhar.

|Agora pq eu não preciso de cursores bidirecionais? {...}
|parametrização são mandados 200 em 200 p/ o cliente; e se ele quiser
|voltar os últimos 200?

Não precisaria se vc usa-se tabelas de memória no cliente (se não quer implementá-las, existem várias muito boas por ai).

Dai vc apenas mandava os registros (de 200 em 200 por exemplo) na sequencia e o cliente armazena os dados na tabela de memória e navega apenas na estação, sem precisar retornar ao servidor -- ou seja:: se desejar retornar os últimos 200 registros, navega na tabela de memória.

Até pq, se o cliente já recebeu os 1ºs 200 registros qual o sentido de ir buscá-los novamente?? É só mais tráfego de rede (e isso não queremos não é mesmo?!)


|Hoje o servidor faz isto na mesma query por bookmarks e o Dataset
|tem que ser bidirecional.

Pois é... não seria mais prático se a navegação fosse no cliente e não no servidor? O servidor seria responsável apenas por requisitar os dados do banco e enviá-los ao cliente (aos poucos)

Bom -- isso é só uma forma de trabalho, em geral a utilizada pelas tecnologias existentes -- mas, pode ser q a sua seja melhor para o seu caso.


|No meu caso não pq utilizo reaproveitamento de objetos e nunca sei se
|aquele TIBQuery vai ser utilizado novamente, por isso a cada Execsql eu
|tenho que dar o Commit no IBTransaction daquela query.

Entendo. Mas vc quer dizer a cada ´requisição do cliente´ não é?? Pq vc provavelmente executa vários ExecSQL dentro do contexto de 1 mesma transação apenas não?? Do contrário cadê a [color=red:0f2c8ad314]atomicidade[/color:0f2c8ad314] não é mesmo?


|Só não entendí essa serialização dos dados que o banco faz com apenas
|uma conexão

Tendo apenas 1 conexão as chamadas no servidor vão ser serializadas ou seja, se 10 clientes executarem comandos ao mesmo tempo, os comandos entram numa fila e cada um tem q esperar o outro ser executado para poder passar.

Isso é realmente MUITO ruim!!!

É correto é ter 1 conexão (IBDatabase) por cliente (Thread) pq assim vc aproveita o servidor. Para evitar a ´demora´ de uma conexão, é muito comum a criação de pools de conexão para a as conexões estejam disponíveis quando o cliente (nova thead) a requer.

(OBS: No caso do IB 6.0 isso é tb importante pq o cliente não é implementado para ´multi-thread´ -- usando a mesma conexão)


T+

Afarias, acho que entendí seu ponto de vista, ou seja, o servidor só lê p/ frente e a tabela do cliente só vai aumentando. O problema é que existem máquinas ainda com 16 MB de memória. Outra questão é por ex se o cliente solicitar um .Last na tabela, o servidor terá que mandar todos os 10.000 registros? E se todos fizerem isso, pois é muito simples clicar num botão de (vá p/ o fim).

É mais ou menos assim: Quando o cliente quer alguma coisa do banco de dados, ele envia a solcitação, nesta solicitação é enviado o ´Handle´ da query que na primeira vez é -1.
O servidor quando vê um Handle -1, ele solicita ao objeto de conexão um TDataset, executa a solicitação e devolve ao cliente juntamente com o ´Handle´ do novo TDataset instanciado.
Da segunda vez em diante, que o cliente cliente solicitar, ele aproveita aquele TDataset já criado. O servidor possui um TList de Datasets para serem reaproveitados.


Quer dizer que o banco executa primeiro uma solicitação para depois executar outra?
Pensava que os bancos trabalhassem mais ou menos como Threads também.

|Afarias, acho que entendí seu ponto de vista, ou seja, o servidor só lê p/
|frente e a tabela do cliente só vai aumentando.

É


|O problema é que existem máquinas ainda com 16 MB de memória.

hehehehe... foi o q imaginei no seu caso -- são como ´terminais burros´

Bom, eu diria q hoje em dia hardware não é problema pois o custo é muito baixo -- mas, :) cada caso é um caso!


|Outra questão é por ex se o cliente solicitar um .Last na tabela, o
|servidor terá que mandar todos os 10.000 registros? E se todos fizerem
|isso, pois é muito simples clicar num botão de (vá p/ o fim).

É sim... por isso, numa implementação assim eu não colocaria esse botão onde pudesse haver MUITOS registros (na verdade, nem tem sentido ele existir né?!)

Muda-se a implementação -- mudam os problemas! :) O importante é sempre trocar problemas maiores por menores! ;)

O grande lance q vc pode estar esquecendo é q o principal é o uso de consultas parametrizadas ... eu ´nunca´ tenho nos meus sistemas consultas q retornem 10.000 registos por exemplo.


|É mais ou menos assim: Quando o cliente quer alguma coisa do banco
|de dados, ele envia a solcitação, nesta solicitação é enviado o ´Handle´
| {...}

Até ai não entendi o q tem q ver com as transações. Mas, acredito q deve estar tudo Ok.


|Quer dizer que o banco executa primeiro uma solicitação para depois
|executar outra?

SIM


|Pensava que os bancos trabalhassem mais ou menos
|como Threads também.

E trabalham! :) (no Interbase apenas na versão SuperServer) Mas a thread é para a conexão:: cada conexão é uma nova tread que vai cuidar dos ´requests´ dela

1 conexão = 1 thread

Dai, se vc usa uma conexão apenas para várias threads é como usar um canudinho apenas para várias pessoas tomando um refrigerante!! :D

É melhor dar 1 canudo para cada uma não?! ;)


T+

Existe por uma questão de praticidade e é por isso que o cliente navega e interage com o servidor sempre de 200 em 200 ou conforme a parametriazação daquela tabela. A query c/ 10.000 registros fica lá no servidor aberta, Por ex, se o cliente solicitar um ListView em ordem alfabética? eu não vou ter que ter a query inteira aberta?
É claro que existe também consultas para os campos do grid, mas aí é aberta outra query e retornado o resultado dessa consulta para no caso de se querer a letra Z, não ter que clicar no botão de próximos 50 vezes.

Por ex, o cliente solicita um Update, depois desliga a máquina e vai embora pra casa. Aquele TIBquery ficaria com a transação aberta?
Após o ExecSQL, automaticamente aquele Dataset é liberado p/ ser reutilizado por outras solicitações sem ter que instanciar um novo TDataset.
Eu sei que existe um default onde vc pode colocar AutoCommited ou coisa parecida quando o objeto é liberado(.Free), mas e se a máquina trava, ou cai a energia?
Não é melhor efetivar a transação logo após o ExecSql ?

Agora quanto às operações do banco serem em série p/ a mesma conexão, se for isso mesmo, vou ter que repensar.
Mas num tabela de Ceps c/ 80.000 regs, 5 clientes deram .Last ao mesmo tempo e os resultados chegaram praticamente juntos.

|Existe por uma questão de praticidade e é por isso que o cliente navega
|e interage com o servidor sempre de 200 em 200 ou conforme a
|parametriazação daquela tabela.

Em geral não acho útil navegação em registros assim... principalmente em 10.000 registros!

SQLs são MUITO mais eficientes! Em vez de abrir 10.000 registros no servidor, tenho o cliente passando um parêmetro e recebendo apenas 200 registros requisitados naquele momento.


|A query c/ 10.000 registros fica lá no servidor aberta, Por ex, se o
|cliente solicitar um ListView em ordem alfabética? eu não vou ter que
|ter a query inteira aberta?

Vc já pensou bem nisso? Um usuário navegando 10.000 registros??


|É claro que existe também consultas para os campos do grid, mas aí é
|aberta outra query e retornado o resultado dessa consulta para no caso
|de se querer a letra Z, não ter que clicar no botão de próximos 50
|vezes.

Muito melhor


|Por ex, o cliente solicita um Update, depois desliga a máquina e vai
|embora pra casa. Aquele TIBquery ficaria com a transação aberta?

Claro q não! Após TODOS os updates serem realizados a transação deve ser fechada com Commit!

Não é isso?!


|Após o ExecSQL, automaticamente aquele Dataset é liberado p/ ser
|reutilizado por outras solicitações sem ter que instanciar um novo
|TDataset.

Neste caso não faz diferença... instanciar um DataSet não ´dá trabalho´ mesmo...


|Eu sei que existe um default onde vc pode colocar AutoCommited ou
|coisa parecida quando o objeto é liberado(.Free),

O DefaultAction existe ... mas o bom é sempre controlar manualmente (explicitamente) as transações


|mas e se a máquina trava, ou cai a energia?

É o tipo de coisa q não se tem o q fazer! O usuário perde as atualizações não comitadas (normalmente quando se perde algo é muito pouca coisa)


|Não é melhor efetivar a transação logo após o ExecSql ?

Não exatamente -- pq assim vc perde o conceito de atomicidade! Vamos dizer q vc deseja salvar um mestre-detalhe (uns 5 registros) vc só deseja o COMMIT após TODOS os registros terem sido incluidos não é mesmo?!

(ou seja, vários ExecSQL e só depois o Commit)


|Agora quanto às operações do banco serem em série p/ a mesma
|conexão, se for isso mesmo, vou ter que repensar.

É isso sim -- como te disse, a solução é muito simples, apenas realize 1 conexão para cada thread!

E ainda melhor, implemente um pool de conexões -- no caso do Interbase, usando IBX, use o componente IBConnectionBroker que é bem simples.


|Mas num tabela de Ceps c/ 80.000 regs, 5 clientes deram .Last ao
|mesmo tempo e os resultados chegaram praticamente juntos.

Não acho q esse teste mostre muita coisa não... apenas o fetch das informações. Fora q ´chegar ao mesmo tempo´ não significa ´chegar RÁPIDO ao mesmo tempo´ ;)

Procure medir o tempo de resposta (no servidor) de várias consultas sendo executadas ao mesmo tempo.

No mais, me parece muito equivocado esse procedimento de abrir uma tabela de CEPs de 80.000 registros!


T+

Bom, citei tabelas de 10.000 ou 80.000 no caso de ceps, mas estas quantidades são raras de serem utilizadas pq utilizo o conceito de hierarquia de chaves por ex: Empresa/Filial/Clientes, então ao não ser para relatórios, nunca terá um cursor de todos os clientes de todas as filiais daquela empresa; numa tela de manutenção de clientes por ex, o grid de clientes fica vazio até que Empresa e Filial sejam informadas.

Agora quanto aos objetos, eu procuro sempre reutilizá-los ou liberá-los na medida do necessário; instanciar um objeto não dá trabalho, mas gasta memória.

Quanto a salvar um master/details, como no momento são 3 bancos, eu utilizo StartTransaction, assim fica transparente para todos eles.
A aplicação cliente não sabe qual banco está sendo utilizado, de uma hora pra outra o banco pode mudar, então eu não me prendo às particularidades específicas de cada banco como por ex triggers, storedprocedures são feitas via comandos sql.
Daí já me perguntaram, não fica mais lento? Não sei pq nunca medí, mas mesmo ficando um pouco mais lento, a flexibilidade de se trabalhar com vários bancos acho que compensa.

|instanciar um objeto não dá trabalho, mas gasta memória.

Mantê-lo instanciado é q ´gasta´ memória! :D


|Quanto a salvar um master/details, como no momento são 3 bancos, eu
|utilizo StartTransaction, assim fica transparente para todos eles. {...}

Não entendi o q uma coisa tem a ver com outra! Qualquer SGBD q vc use tem o mesmo conceito de atomicidade! E nada tem a ver com a sintaxe de abrir ou fechar a transação, ou com triggers e procudures!


|Daí já me perguntaram, não fica mais lento? Não sei pq nunca medí,
|mas mesmo ficando um pouco mais lento, a flexibilidade de se trabalhar
|com vários bancos acho que compensa.

É... ganha-se aqui, perde-se ali! Perticularmente não abro mão de trabalhar com todos os recursos q os SGBDs implementam.



T+

A memória já foi gasta e ele é reaproveitado p/ futuras solicitações, senão seriam dois trabalhos, um de liberar o objeto antigo e outro de instanciar o novo, além do que a aplicação cliente já tem o Handle do dataset p/ utilizar e reutilizar. No final quando o cliente se desconecta, sua thread é liberada juntamente com todos seus datasets.


O que eu disse foi que neste caso, o cliente manda um comando de StartTransaction, não importando qual banco é utilizado.
O Commit que é dado p/ o Interbase é específico p/ qualquer ExecSql, desde que o banco não esteja inTransaction, senão o Commit não é dado e quem manda dar é a aplicação cliente e se ela não der por qualquer motivo, o servidor dá um Rollback quando da sua desconexão.