A Tigger is the only valid option if you want accurate notification. Something that runs from time to time may work in some very specific scenarios, but "always" will have a lower performance. Unless what you want is not to check from time to time and the update cycle is too high, which does not seem to be the case.
The trigger ensures that every change in the bank makes the notification. You may want this. You may wish from time to time to have notifications of everything. They are different semantics.
The trigger has a cost in each operation, if you don’t need these notifications on time, it can be a cost for nothing.
Making checking batches has an extra single cost and it will do unnecessary operations, but relieves each update and can choose to do so at non-critical time. It won’t change much, but in large volumes it can make a difference. Can you leave the notification for later without problems? Will you do it often? Then I doubt it’s a good option.
Take a test to see which one works best for you. It’s not easy to choose, it depends on the need and how to implement. The danger is in detail.
This site here chooses to update certain things in batch, but some are done on time. It depends on the desired and how much it affects the established performance metric.
In some databases there are better options than using cron
.
Of course it depends on the architecture of your solution. I am considering what you want to do in the database. In general I prefer to do in another layer.