SQL is intended as a declarative query language. That it is not the correct tool for imperative processing of updates feels expected? And mostly fine?

Fair that things often grow beyond their original intent.

▲

SkiFire13 a day ago | parent | next [-]

If you don't use SQL for this you'll need to reimplement your external locking for this, even though databases already implement it.

	▲	taeric a day ago \| parent [-]
		For the example of an account, moving to double entry accounting is probably the correct move. With an external reconciliation process to take action if they don't match. But, that "external" part is what trips up a lot of people. Few things are confined to only exist within the database. Such that sometimes you can't do locks that accurately portray what we can order outside of the computer system. Think legal clawbacks and the like.

▲

2 days ago | parent | prev | next [-]

[deleted]

▲

traderj0e 2 days ago | parent | prev [-]

You run into the same issues without using the weird imperative syntax in this article.

	▲	taeric 2 days ago \| parent [-]
		Fair. It would help if the examples didn't always fallback to processes that should have reconciliation procedures to cover when they differ. Double entry accounting combined with the necessary follow on processes can't be "coded away." Which is to say that I am definitely indexing on the idea that you would try and get a query language to encode processes being the problem, here.