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

[José Otávio Lussari]

Gostei dessa sua idéia... mas pra vc saber que tinha mais do 300 fotos, vc
implementou oq?
Já pensei em colocar em minhas telas de consultas um Select first 300... mas
fazendo assim, ele nunca irá trazer mais do que 300 e não saberei se os
parâmetros que o usuário passou realmente retornaria mais de 300... certo?

Penso nesses detalhes pelo seguinte: Desenvolvi um projeto de memória de
calculo aqui na empresa e quando liberei o sistema para produção, eu
acompanhei o usuário por um determinado tempo. Minhas telas de consultas era
liberadas, não tinha bloqueio! Eu deixei as opções de consultar por alguns
campos chaves e com as opções: Iniciados com, que contenham e Seja igual.

Certo dia voltei acompanhar o usuário para explicar uma nova atualização e
para minha surpresa ele estava fazendo o seguinte: Escolheu um campo que
tinha em comum com todos os produtos e digitava uma letra em comum com todos
os registros, que no caso era o "W", ou seja, ele sempre trazia todos os
registros da tabela e depois ficava procurando um a um na Grid... não me
pergunte porque ele fazia isso, pois jamais eu entenderei isso... rsrsrs

Agora, estou com outro projeto em IBX e como ele vai crescer, comecei migrar
para IBO. Como eu sei que vai acontecer isso novamente, quero encontrar
alguma forma de obrigar o usuário filtrar mais as consultas... nesse projeto
que mencionei acima, eu coloquei vários bloqueios nas consultas, entre elas
um intervalo de no Maximo 3 meses entre datas e trazer apenas os 30
primeiros registros... fechei mesmo!!! 
Agora nesse projeto que estou migrando, estou estuando a melhor forma
possível de lidar com isso e por isso que estou recorrendo a vocês..
entendeu?
obrigado pelas dicas amigo!

atenciosamente,

[ ]’s
José Otávio Lussari
Analista de Sistemas
Bacharel em Sistemas de Informação

-----Mensagem original-----
De: lista-bounces em firebase.com.br [mailto:lista-bounces em firebase.com.br] Em
nome de Eduardo Jedliczka
Enviada em: terça-feira, 25 de janeiro de 2011 08:32
Para: FireBase
Assunto: Re: [firebase-br] RES: Dúvida com TIB_Query x TIBODataset
(Performance)

(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.
>
>

______________________________________________
FireBase-BR (www.firebase.com.br) - Hospedado em www.locador.com.br
Para saber como gerenciar/excluir seu cadastro na lista, use:
http://www.firebase.com.br/fb/artigo.php?id=1107
Para consultar mensagens antigas: http://firebase.com.br/pesquisa