The problem is that putting code into your database has all the problems of data migration with no testability. It's really hard to write tests and debug code compared to a proper language.
Haven’t worked with Oracle in over a decade, but SQL Server’s tooling is actually quite decent in that regard. You can attach the Visual Studio debugger to a T-SQL stored procedure, set breakpoints, step, inspect variables etc. There are rough edges, but it’s good enough to be useful.
Automated tests of T-SQL stored procedures are also possible. There are couple of ways you could do that, but in our case we just write “unit” tests in C# which call the procedures. This integrates nicely into Visual Studio’s Test Explorer, is debuggable etc. You can even step through a C# test, and then just “step into” T-SQL being called from there!
There are valid reasons for not putting business logic into stored procedures, but “not being a proper language” is probably not one of them, at least in the case of T-SQL. Then again, there are also reasons for using stored procedures. Everything is a tradeoff…
I took over support for a small ISP after the previous sysadmin died unexpectedly. He was a big fan of putting code in the PostgreSQL database, which I had never done before. That was fun to figure out and debug issues.
