3 ms·
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 t
by taeric 5mo ago
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.
- deleted 5mo ago[deleted]
- traderj0e 5mo agoYou run into the same issues without using the weird imperative syntax in this article.
- taeric 5mo agoFair. 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.
- SkiFire13 5mo agoIf you don't use SQL for this you'll need to reimplement your external locking for this, even though databases already implement it.
- taeric 5mo agoFor 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.