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

Eduardo Jedliczka edujed em gmail.com
Qua Jan 26 17:41:16 -03 2011 

explicitamente neste caso, NÃO seria interessante criar a transação.

O mais aconselhável é ter uma única transação global read-only para
este tipo de coisa.

Leia com calma aquele post do Artur Anjos (ok, sei que PT-PT às vezes
precisa de tradução para PT-BR) e faça o teste que ele explica, você
vai entender o que quero dizer.

abraço

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




Em 26 de janeiro de 2011 15:37, José Otávio Lussari
<tavinhol em gmail.com> escreveu:
> Ok Eduardo!
> mas vc acha que deveria fazer isso tbem?
>
> function Conta_Registro(SQL_Count: String): Integer;
> var Contar: TIB_Query;
>    Trans: TIB_Transaction;
> begin
>   Contar:= nil;
>   Contar:= TIB_Query.Create(Contar);
>   Contar.IB_Connection:= DMGeral.IB_Connection;
>
>   Trans:= TIB_Transaction.Create(nil);
>   Trans.IB_Connection:= DMGeral.IB_Connection;
>   Trans.ReadOnly:= True;
>
>   Contar.IB_Transaction:= Trans;
>
>   with Contar do begin
>      Close;
>      SQL.Clear;
>      SQL.Add(SQL_Count);
>      Open;
>   end;
>
>   Result:= Contar.fieldByName('COUNT').AsInteger;
>   Contar.Close;
>   Contar.Unprepare;
>   If Assigned(Contar) then FreeAndNil(Contar);
> end;
>
> Seria isso, ou não é preciso criar uma TIB_Transaction?
>
> 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: quarta-feira, 26 de janeiro de 2011 14:53
> Para: FireBase
> Assunto: Re: [firebase-br] RES: RES: RES: RES: RES: Dúvida com TIB_Query x
> TIBODataset (Performance)
>
> é importante que entre:
>  Result:= Contar.fieldByName('COUNT').AsInteger;
>  If Assigned(Contar) then FreeAndNil(Contar);
>
> tenha:
>
> contar.close;
> contar.unprepare;
>
> Assim, a query será fechada e despreparada no servidor. Se a query
> ficar "por alguma razão" preparada, a transação PODE ficar aberta.
>
> mas à grosso modo é isto. Apenas verifique os métodos da SESSIONPROPS
> (existe muita mágica feita por este cara além de mudar a cor dos
> edits)
>
> veja mais detalhes nas mensagens antigas (um bom ponto de partida é
> este aqui:
> http://mail.firebase.com.br/pipermail/lista_firebase.com.br/2008-April/05120
> 2.html)
>
> ==========================
> Eduardo Jedliczka
> Apucarana - Pr
> ==========================
>
>
>
>
> Em 25 de janeiro de 2011 16:18, José Otávio Lussari
> <tavinhol em gmail.com> escreveu:
>> Ok Eduardo, obrigado pela explicação : )
>> Agora, vamos la: Vc disse que o IB_Query tem uma aba transaction! Vc quis
>> dizer o IB_Connection, não foi?
>> Eu criei uma função que efetua esse count e retorna o numero de registros
> da
>> SQL "Count"...
>>
>> function Conta_Registro(SQL_Count: String): Integer;
>> var Contar: TIB_Query;
>> begin
>>   Contar:= nil;
>>   Contar:= TIB_Query.Create(Contar);
>>   Contar.IB_Connection:= DMGeral.IB_Connection;
>>
>>   with Contar do begin
>>      Close;
>>      SQL.Clear;
>>      SQL.Add(SQL_Count);
>>      Open;
>>   end;
>>
>>   Result:= Contar.fieldByName('COUNT').AsInteger;
>>   If Assigned(Contar) then FreeAndNil(Contar);
>> end;
>>
>> Até então, eu não estava colocando um TIB_Transaction como vc vê no codigo
>> acima!
>> Seguindo a lógica acima, como eu trabalharia com transação nesse código?
>> eu iria "startar" ela em qual momento? Transação Read Only tem que ser
>> finalizada com COMMIT, ROLLBACK?
>>
>> Veja que eu tbem tenho uma função para criar transações:
>>
>> function TDMGeral.CriarTransacao(Owner: TComponent): TIB_Transaction;
>> var
>>   ib_Transacao: TIB_Transaction;
>> begin
>>   ib_Transacao:= TIB_Transaction.Create(Owner);
>>   ib_Transacao.IB_Connection:= IB_Connection;
>>   Result:= ib_Transacao;
>> end;
>>
>> Desculpe a chuva de perguntas amigo, mas vc tocou em um ponto fraco meu
>> "ainda"... Transações...
>>
>> 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 16:02
>> Para: FireBase
>> Assunto: Re: [firebase-br] RES: RES: RES: RES: Dúvida com TIB_Query x
>> TIBODataset (Performance)
>>
>> Transações... kkk... agora você fez uma boa pergunta.
>>
>> Quando falamos de qualquer componente de acesso, sempre há duas formas
>> de se trabalhar com transações: explicitas ou implicitas.
>>
>> As implicitas geralmente são (ou deveriam ser) controladas
>> automaticamente pelos componentes de acesso. O problema é que a
>> maioria dos componentes, abre uma transação ad-eternum (ou seja, só
>> fecha quando termina o aplicativo) e isto gera vários problemas de
>> performance.
>>
>> As explicitas são controladas pelo próprio desenvolvedor.
>>
>> Isto também vale para o IBO, só que ele tem alguns recursos extras,
>> por exemplo, se você não setar um transaction para uma query, o IBO
>> irá criar uma nova transação especialmente para aquela query (veja que
>> o IB_QUERY tem uma aba transaction).
>>
>> Assim, pode-se desenvolver um sistema grande usando quase que
>> totalmente transações automáticas. A excessão fica para aquelas
>> operações que realmente exigem um controle, como por exemplo uma
>> tranferência de carteira, o lançamento contábil que não seja da 1ª
>> forma, uma baixa de múltiplas duplicatas, etc.
>>
>> Mas é preciso alterar (via código) algumas propriedades, para que as
>> transações automáticas realmente sejam fechadas (este código já foi
>> postado várias vezes aqui na lista).
>>
>> Quanto ao isolation, também depende muito da rotina. Mas geralmente
>> (telas de cadastros simples, por exemplo) eu uso auto-commit,
>> read-commited, wait transaction.
>>
>> lembre-se diferente de outros bancos, no firebird, um SELECT EXIGE uma
>> transação ativa.
>>
>> ==========================
>> Eduardo Jedliczka
>> Apucarana - Pr
>> ==========================
>>
>>
>>
>>
>> Em 25 de janeiro de 2011 14:52, José Otávio Lussari
>> <tavinhol em gmail.com> escreveu:
>>> Ok Eduardo, mas me fale uma coisa por gentileza: Vc diz estar em uma
>>> transação separada da transação da query em questão!
>>> Entao eu teria um outro TIB_Transaction ligado nessa query com a opção
>>> ReadOnly marcada, é isso?
>>> e em Isolation, o que eu deixaria marcado?
>>> Vc colocou uma outra duvida pra mim: Uma IB_Query que eu uso apenas para
>>> Select's precisa ter um TIB_Transaction?
>>> Desculpe amigo, como eu disse sou novato em IBO...
>>>
>>> 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 14:36
>>> Para: FireBase
>>> Assunto: Re: [firebase-br] RES: RES: RES: Dúvida com TIB_Query x
>> TIBODataset
>>> (Performance)
>>>
>>> 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
>>>>>
>>
>> ______________________________________________
>> 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
>>
>
> ______________________________________________
> 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