[tacticaldev]

I'm currently part of a team trying to UNDO this very concept. It sounded great in the beginning, but after years of headaches and wasted cash; we're building the backend in something else. I wasn't part of the original team. Nor was I part of the decision to migrate off of the system. I just know that for my employer, it was a bad decision those many years ago...

[gnat]

Could you be more specific about the problems you're hoping to fix/benefits you're hoping to gain by dragging the backend logic out of the database?

[magicalhippo]

We're staying away from stored procs as far as possible. For us the main driver is that it would make it harder to run older versions of our program alongside newer versions.

We rely on this to be able to bring updates quickly to our customers when their needs change.

We also found the tooling lacking for our database server.

On the other hand, we don't use ORMs, instead mostly relying on handwritten select queries, with "dumb" insert/updates being handled by library and others by hand. So we normally don't pull more data over the wire than we need.

Then again, I guess we're a bit old fashioned.

[pjmlp]

Sure, because wasting network bandwith for going through needless data on the client is such a clever idea.

[sumtechguy]

This takes a balance to get right. For some data yes drag it over and keep it on the 'client'. But for other data just join it out and let the SQL handle it. However, for some reason SQL seems to scare a lot of people. So they end up making lots of microservices/functions/methods that just drag the data together and mash it together in a language they understand. That comes at a cost of network bandwidth.

I found that if you are 'happy' with the style of lots of stored procs and data lifting on the server side you usually have a decent source delivery system in place. If you do not have that you will fight every step of the way changing the schema and procs as this monolithic glob that no one dares to touch.