Colleague: I'll write a stored procedure that does fully qualified database table path names to access data from the other databases and then do business logic with all of it in the same proc.

Me: That will be 600 lashings.

Nope, we strap 3 or 4 databases together and multiple tables from each to drag out a subset of data in a single query.

@C0D4 there are exceptions, of course, where something like that can make sense.

I don't think it should never be the norm, though.

Outside of the exceptions, writing code like that forces a certain infrastructure behind it, which is a smell. The code shouldn't be the one to dictate that. In this example, all the databases involved have to have visibility to each other. They have to be on the same machine or on a network where they can communicate driven by the proc's instructions. They're tightly coupled which hinders the ability to scale easily.

@duckWit there sarcasm was in that,

I have a project - well a few projects under an umbrella, that did this, several databases tied together with a lot of queries retrieving data from all of them regardless of the sub projects scope.

Micro services or even domain based APis were not the norm for this lot back in the day.

Luckily it's months away from shutting it down, I don't need to have a stroke trying to unpick it.

@C0D4 gotcha. Honestly we have the same issue over here in our legacy code. We used to do those kinds of practices, and over the course of the last couple years we've been spending so much effort shifting away from it into a microservice architecture (which is such a breath of fresh air). This recent proposal prompted the "lashings" comment because, "Don't you dare undo all our work by making more tangled messes!"