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

Magno System magnosysteminformatica em gmail.com
Ter Jan 25 11:14:39 -03 2011


Você pode fazer um
SELECT FIRST 1 SKIP 300 FROM TABELA

Se retornar algum registro tem mais de 300.


----- Original Message ----- 
From: "Eduardo Jedliczka" <edujed em gmail.com>
To: "FireBase" <lista em firebase.com.br>
Sent: Tuesday, January 25, 2011 11:00 AM
Subject: Re: [firebase-br]RES: RES: Dúvida com TIB_Query x TIBODataset 
(Performance)


Na época eu não usava o IBO, então usava o RowNum mesmo.

Mas dá para fazer (logo após o open da procura) uma espécie (ok, eu
sei que há uma função específica para isto, mas faz algum tempo que
nem tenho windows na minha máquina, quem dirá delphi).

x := 0;

while (x <= 300) and not qy.eof() do
  begin
    qy.next;
    inc(x);
  end;

if x >300 then
  label.caption := 'retornou mais de 300 registros'
else
  label.caption := inttostr(x) + ' registros';

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

Em 25 de janeiro de 2011 08:52, José Otávio Lussari
<tavinhol em gmail.com> escreveu:
> 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,
>

______________________________________________
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 





Mais detalhes sobre a lista de discussão lista