Imagine a transferência de 200.000 euros de uma conta bancária para outra. Retira o montante da conta de origem, e depois deposita-o na conta de destino. Até agora tudo é normal e, num mundo perfeito, a operação terá êxito. Infelizmente, aqui, no mundo real, as coisas podem correr mal. Alguma coisa acontece e o dinheiro é perdido. Isso é muito mau.
Bem, as transacções estão aqui para garantir que isto não aconteça com as suas aplicações! Neste post do blogue explore em detalhe a utilização e a importância das transacções, bem como vários cenários mostrando como podem salvar o seu negócio.
O que são transacções?
De acordo com a documentação:
Transacções são uma série de modificações de dados relacionados feitas a uma base de dados dentro de um processo. Uma transacção não é guardada permanentemente numa base de dados até que a transacção seja validada. Se uma transacção não for concluída, seja porque é cancelada ou devido a algum evento externo, as modificações não são guardadas.
É importante notar:
Quando se utilizam transacções aninhadas, o resultado de cada subtransacção depende da validação ou do cancelamento da transacção de nível superior. Se a transacção de nível superior for validada, os resultados das subtransacções são confirmados (validação ou cancelamento). Por outro lado, se a transacção de nível superior for cancelada, todas as subtransacções são canceladas, independentemente dos seus respectivos resultados.
Certifique-se de verificar a documentação para obter informações mais aprofundadas sobre as transacções.
utilizando Transacções
É difícil imaginar aplicações comerciais que não utilizam transacções, mas de vez em quando já as vi! Ao discutir esta falta de transacções com os criadores de aplicações, já ouvi frases como “oh, funcionou até agora”, ou mesmo “sempre tivemos sorte”. Na minha opinião, a sorte não deveria ser um conceito de design para aplicações comerciais.
Um exemplo clássico de utilização de transacções é a contabilidade. As demonstrações financeiras fornecem um registo de duas categorias: activo e passivo. Ambas precisam de ser calculadas e guardadas (completamente, nunca parcialmente), ou não tocadas de todo.
Outro exemplo é um sistema de expedição, em que a criação de uma encomenda diminui o inventário no armazém. Em vez de confiarmos na sorte, precisamos de assegurar que tanto a ordem como os registos de inventário são criados ou modificados em conjunto. Aconteça o que acontecer, ou ambas as operações são concluídas ou canceladas.
Pode-se pensar numa transacção como uma espécie de grande parêntesis:
- Abre-se (START TRANSACTION comando),
- realizar operações na base de dados (criar/modificar/eliminar registos – de uma ou várias tabelas),
- depois fechá-la, validando-a (VALIDATE TRANSACTION comando) ou cancelamento (CANCEL TRANSACTION comando) TODAS as operações.
Além de operações de base de dados de baixo nível, outro bom caso para fazer uso de transacções é uma interface de utilizador. Imagine um formulário de introdução de facturas, utilizando uma caixa de listagem (ou subformulário) com itens do produto (armazenados noutra tabela) … ou clientes e contactos … ou contactos e números de telefone. A lista continua e continua em ….
O seu utilizador deseja modificar uma factura. Podem alterar um ou vários itens, depois decidir finalmente clicar no botão cancelar e assumir que todas as modificações de itens da factura são invertidas (não guardadas). Poderá tratar disto com matrizes complexas ou simplesmente utilizando uma transacção.
Esperemos que já esteja a utilizar transacções.
utilizando Transacções Aninhadas
Cenário um: uma aplicação de Contacto
Digamos que tem uma estrutura simples com 2 mesas: clientes e contactos. Tem um formulário de entrada de clientes incluindo uma caixa de listagem de registos de contactos. Um duplo clique sobre um registo abre um formulário de entrada de contacto com mais detalhes para o contacto.
Eis o que pode acontecer:
- Um utilizador final abre um registo de cliente e modifica o nome da rua.
- Depois, abre o contacto ‘A’, modifica a data de nascimento, e fecha o formulário de contacto clicando num botão OK.
- Seguem este procedimento abrindo o contacto ‘B’, modificando algo, e depois decidem cancelar as suas alterações.
- Agora de volta ao formulário de cliente, o utilizador final clica num botão OK para completar as suas actividades.
O utilizador espera que a sua modificação do contacto ‘A’ seja guardada, enquanto que a modificação para o contacto ‘B’ não é. As alterações ao próprio registo do cliente também devem, evidentemente, ser guardadas.
Com as transacções aninhadas, isto é facilmente manuseado. Basta utilizar uma transacção no formulário de cliente, e outra transacção no formulário de contacto. Não se preocupe!
Cenário dois: processamento automático em lote
Um cenário completamente diferente – mas com o mesmo conceito – é o processamento automático por lotes (cálculos, importação, etc.):
- No meio de um trabalho de lote complexo, é necessário parar o processo por alguma razão(por exemplo, encontrou dados maus ou um pedido do utilizador para cancelar/quitar).
Com uma transacção de nível único, só se pode cancelar todas as operações – ou parar no meio, resultando numa situação pouco clara. Pode estar a pensar “Eu não pararia no meio, terminaria a operação antes de parar”. Isso é óptimo, mas como lidaria com cortes de energia, colisões, falhas de hardware e outros erros inesperados?
Uma vez que não pode … e contar com a sorte não é fiável … o sistema deve ser concebido para assegurar dados fiáveis.
tenha em mente…
As transacções dão-lhe controlo sobre este tipo de situações. Utilize transacções individuais para cada operação (importação de dados, realização de cálculos, etc.) aninhadas numa transacção de nível superior (para permitir o cancelamento ou a validação de todas as operações).
Se uma transacção não for concluída por qualquer razão (falha, corte de energia, etc.), não tenha medo! Cada operação já realizada é desfeita porque ainda nada foi validado pela transacção de nível superior.