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

Eduardo Jedliczka edujed em gmail.com
Ter Jan 25 14:36:19 -03 2011


Sem sombra de dúvidas, esta proposição é muito melhor do que o
FetchAll, mas há um grande inconveniente:

- São duas operações de busca no banco de dados. E isto pode gerar um
pequeno overheat no banco de dados (se a tabela for grande ou se o
select tiver muitos joins);

Para isto, seria interessante que a Query que traz o count estivesse
numa transação separada (read-only) e pudesse ser executa após o OPEN
do grid.

Se você ainda deseja exibir numeros reais e absolutos, este método
parece ser melhor, mas se você contenta-se em mostrar um "tem mais do
que X", a solução apresentada pelo magno também é boa.

abraço,

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

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