>>IMO, transaction is suited for applying changes to multiple tables at the same time and dynamically.

Not sure what the dynamic aspect is... I am not sure where the big complication exists here.. Transactions provide the ability to have all updates committed or rolled back. In other words, in the confines of a transaction, it is an all or nothing proposition - (the ACID principle...). While you may use buffering, unless you use transcations, you run the risk of having only part of your updates committed. Good examples include accounting-based apps. Both the debit and credit updates need to be committed. If one does not commit, the other should not...

It is a fairly simple concept.......