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

Ter Jan 25 11:11:49 -03 2011

Certo Eduardo! Entendi perfeitamente sua lógica!
Mas vc acha que ao montar uma SQL de consulta conforme os critérios do
usuário, eu montar juntamente uma SQL "Count", eu estaria perfendo
performance?
Pois um SELECT COUNT me retorna apenas um numero! Vc não acha que seria mais
vantajoso fazer algo do tipo:

var x: Integer;

SQL_Usuario: SELECT CAMPO1, CAMPO2 FROM TABELA WHERE CAMPO2 LIKE
'Parafuso%';

SQL_Count: SELECT COUNT(*) FROM TABELA WHERE CAMPO2 LIKE 'Parafuso%';

x:= SQL_Count;

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

O você acha?

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 11:00
Para: FireBase
Assunto: 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