[firebase-br] RES: Dúvida com TIB_Query x TIBODataset (Performance)

[Eduardo Jedliczka]

(perdoem-me se esta resposta chegar duplicada na lista)

o Magno System está certo, é exatamente este o comportamento.

Existem poucas justificativas para ter uma tabela grande com FetchAll.
Na maioria das vezes, deixar o IBO controlar é muito melhor, pois a
performance será melhor para o Usuário, pois o FetchAll realmente
custa MUITO caro.

Lembre-se usar um banco relacional não é a mesma coisa que uma
aplicação desktop. O ideal é sempre retornar o MÍNIMO possível de
registros para a estação/cliente.

Mas, tente explicar o seu cenário, e talvez possamos encontrar juntos
uma solução.

Se for para usar um "locate", é melhor e mais rápido refazer o select
(dinamicamente).

Quanto à exibir a quantidade de "registros" encontrados numa busca, eu
sinceramente acredito que o desperdício de processamento não justifica
para isto.

Certa vez, tive que fazer um controle de fotos, lugares e pessoas para
um pequeno jornal aqui da região. Eles possuiam mais de 1 milhão de
fotos (entre negativos e fotos reveladas), e estavam digitalizando
todo o acervo, mas por hora estavam controlando em qual armário,
gaveta e divisão cada foto estava.
Como haviam muitas fotos, a equipe do jornal queria saber quantas
fotos haviam  sido retornadas pela busca, já que seria necessário
olhar "pessoalmente" cada foto no arquivo.
Resolvi implementar uma rotina que só carregava as 300 primeiras
fotos, e se houvesse mais do que isto, na quantidade era exibida uma
mensagem "mais de 300 fotos".
O usuário me perguntou o porquê da mensagem. Eu só respondi: "tem
certeza que você REALMENTE irá olhar foto por foto do arquivo, se já
sabe que há mais de 300 fotos para ver ?"
Ele foi franco e disse "Claro que NÃO. Então como eu faço ?".
Expliquei que era só refinar a busca até que retornasse poucos registros.

Num sistema contábil, faturamento ou financeiro, duvido que alguém
queira buscar "manualmente" por alguma informação correndo um GRID com
mais de 3 mil registros.
Se a pessoa quer saber "exatamente" quantos lançamentos existem numa
determinada data/período, ou de um cliente/fornecedor, pode-se
implementar um lugar próprio para isto.
Mas, no geral, eu simplesmente colocaria um FetchFirst de 500 (ou se a
tabela tiver poucos campos 1.000) registros, com fetchs adicionais a
cada 200 ou 300 registros. E  exibiria "mais de 500 registros".

Abraço,

==========================
Eduardo Jedliczka
Apucarana - Pr
==========================


Em 25 de janeiro de 2011 07:42, José Otávio Lussari
<tavinhol em gmail.com> escreveu:
>
> Bom dia Magno!
> Como vc trabalha para mostrar a quantidade registros encontrados em suas
> consultas?
> Entao vc está me dizendo que o recordcount do IBO já tem um fetchall
> embutido, certo?
> Trabalhava com IBX e com ele se eu nao desse um fetchall, o recordcount me
> retornava uma quantidade falsa!
> Fetchall no IBO já vi que nao é recomendavel, a nao ser que eu tenha certeza
> que irá retornar poucos registros, certo? Vc recomendaria usar o que entao?
> RecordCount? ou junto com minha consulta, criar uma sentença com o count?
> obrigado e desculpe a chuva de perguntas...
>
> [ ]'s
> Otávio
>
> Em 24 de janeiro de 2011 16:59, Magno System
> <magnosysteminformatica em gmail.com> escreveu:
>
> Exatamente isto. A vantagem de usar os componentes nativos do IBO é esta.
> Eles são projetados para cliente/servidor. Particularmente não uso o FETCH
> ALL, até porque se for necessário o IBO o fará automaticamente. Exemplo
> disto é o RECORDCOUNT que já tem um FETCH ALL embutido.
>
>