Fórum manipular transação #39479
15/10/2003
0
Olá pessoal!
Eu tenho um form para a inclusão de registros em uma tabela. Gostaria de saber qual a melhor maneira de manipular a transação, se é que existe alguma diferença em termos de performace do banco.
1º - Iniciar a transação no evento onshow do form e usar o CommitRetaining na hora de dar o Insert. Isso deixaria a transaçao por mais tempo aberta principalmente se o usuário incluir vários registros.
2º Iniciar a transação apenas na hora de incluir - dar o Insert - usar o Commit. As transações seriam rápidas mas aumentaria muito a quantidade de transações( isto é um problema? ) .
Para a minha aplicação a 2ª opção seria mais conveniente, mas em relação ao Interbase ?
desde já agradeço.
Eu tenho um form para a inclusão de registros em uma tabela. Gostaria de saber qual a melhor maneira de manipular a transação, se é que existe alguma diferença em termos de performace do banco.
1º - Iniciar a transação no evento onshow do form e usar o CommitRetaining na hora de dar o Insert. Isso deixaria a transaçao por mais tempo aberta principalmente se o usuário incluir vários registros.
2º Iniciar a transação apenas na hora de incluir - dar o Insert - usar o Commit. As transações seriam rápidas mas aumentaria muito a quantidade de transações( isto é um problema? ) .
Para a minha aplicação a 2ª opção seria mais conveniente, mas em relação ao Interbase ?
desde já agradeço.
Matche
Curtir tópico
+ 0
Responder
Posts
15/10/2003
Afarias
|1º - Iniciar a transação no evento onshow do form e usar o
|CommitRetaining na hora de dar o Insert. Isso deixaria a transaçao por
|mais tempo aberta principalmente se o usuário incluir vários registros.
CommitRetaining após o POST vc quer dizer não é?!
|2º Iniciar a transação apenas na hora de incluir - dar o Insert - usar o
|Commit. As transações seriam rápidas mas aumentaria muito a
|quantidade de transações( isto é um problema? ) .
de qualquer forma a transação já vai estar aberta para a seleção do registro não é??
Se sua aplicação é de pequeno porte , ou em cadastros , isso não te trará muito problema não... só nunca deixe transações abertas ´para sempre´
quando fechar um form (cadastro) para ir para outro... dê um COMMIT na transação (só retaining sempre é ruim)
T+
|CommitRetaining na hora de dar o Insert. Isso deixaria a transaçao por
|mais tempo aberta principalmente se o usuário incluir vários registros.
CommitRetaining após o POST vc quer dizer não é?!
|2º Iniciar a transação apenas na hora de incluir - dar o Insert - usar o
|Commit. As transações seriam rápidas mas aumentaria muito a
|quantidade de transações( isto é um problema? ) .
de qualquer forma a transação já vai estar aberta para a seleção do registro não é??
Se sua aplicação é de pequeno porte , ou em cadastros , isso não te trará muito problema não... só nunca deixe transações abertas ´para sempre´
quando fechar um form (cadastro) para ir para outro... dê um COMMIT na transação (só retaining sempre é ruim)
T+
Responder
Gostei + 0
16/10/2003
Matche
Obrigado pela resposta A.Farias. Só mais uma coisa:
No Interbase existe um limite na quantidade de transações, ou seja, o banco perde em performace se meu sistema criar um número muito grande de transações, mesmo que elas sejam rápidas?
mais uma vez, obrigado.
No Interbase existe um limite na quantidade de transações, ou seja, o banco perde em performace se meu sistema criar um número muito grande de transações, mesmo que elas sejam rápidas?
mais uma vez, obrigado.
Responder
Gostei + 0
16/10/2003
Afarias
|No Interbase existe um limite na quantidade de transações, ou seja, o
|banco perde em performace se meu sistema criar um número muito
|grande de transações, mesmo que elas sejam rápidas?
não, não q eu saiba.
o problema real são transações muito longas com muitas alterações... (ex: vc abre 1 transação no início do programa, faz tudo nela sem fechar -- só usa commitretaining -- e só termina quando fechar o programa!)
Pior ainda são grandes transações com ROLLBACK no final!!
como eu disse, digamos q alguem abre um cadastro de clientes -- dai vc abre uma transação para o cadastro e fica dando comitretaining -- tudo bem -- mas quando o cara for para o cadastro de produtos por ex. de um COMMIT na transação do cadastro de clientes e abra uma nova transação para o cadastro de produtos (claro, se sua aplicação não é MDI -- neste caso o commit é só quando fechar o cadastro de clientes :-)
bom... esta ainda não é das melhores práticas, mas em sistemas pequenos vc não terá nenhum problema.
T+
|banco perde em performace se meu sistema criar um número muito
|grande de transações, mesmo que elas sejam rápidas?
não, não q eu saiba.
o problema real são transações muito longas com muitas alterações... (ex: vc abre 1 transação no início do programa, faz tudo nela sem fechar -- só usa commitretaining -- e só termina quando fechar o programa!)
Pior ainda são grandes transações com ROLLBACK no final!!
como eu disse, digamos q alguem abre um cadastro de clientes -- dai vc abre uma transação para o cadastro e fica dando comitretaining -- tudo bem -- mas quando o cara for para o cadastro de produtos por ex. de um COMMIT na transação do cadastro de clientes e abra uma nova transação para o cadastro de produtos (claro, se sua aplicação não é MDI -- neste caso o commit é só quando fechar o cadastro de clientes :-)
bom... esta ainda não é das melhores práticas, mas em sistemas pequenos vc não terá nenhum problema.
T+
Responder
Gostei + 0
Clique aqui para fazer login e interagir na Comunidade :)