[Nextgrid]

You can model external system interactions with tables representing "mailboxes" - so for example if a DB stored procedure needs to call a third-party API to create a resource, it writes a row in the "outbox" table for that API, then application-level code picks that up, makes the API call, parses the response (extracts the required fields) and stores it in an "inbox" table so now the database has access to the response (and a trigger can run the remainder of the business process upon insertion of that row).

[Tobani]

Yes, but then you've removed parent comments' assertion that everything should be done by the RDBMS. And you've changed the contract of the action.

[TeMPOraL]

Surely some RDBMS has the ability to run REST queries, possibly via SQL by pretending it's a table or something.

I can imagine that working on a good day. I don't dare imagine error handling (though would love to look at examples).

Ultimately, it probably makes no sense to do everything in the database, but I still believe we're doing way too much in the application, and too little in the DB. Some of the logic really belongs to data (and needs to be duplicated for any program using the same data, or else...; probably why people don't like to share databases between programs).

And, at a higher level, I wonder how far we could go if we pushed all data-specific logic into the DB, and the rest (like REST calls) into dedicated components, and used a generic orchestrator to glue the parts together? What of the "application code" would remain then, and where would it sit?