[Scubabear68]

I have worked with systems with nearly 100k lines code in Oracle stored procs, and another legendary place with around 4 million.

It was a nightmare. Deployments were very difficult, there was little tooling, reasoning about the system was difficult, and of course running so much code in Oracle required very expensive licenses.

And it is much harder to hire hard core PL/SQL devs over Java, C#, Python or whatever.

You really don’t want significant code in the DB. It can be useful for some cases, like automating audit tables, but that is about it.

And for triggers - I feel for anyone maintaining business logic located in triggers. What a debugging hell that can be.

[prng2021]

Wow. I was going to say that no one in their right mind would even consider putting all business logic at the database layer. I’m willing to bet there were tons of Oracle-specific features being used too.

[Scubabear68]

Oh, yes, absolutely.

At one point Terradata claimed they had a tool that could auto convert to something else with 99% success rate, or something like that. The reality on our samples we tried was like 40%.

Plus, Pl/SQL code is often very “chatty” with the data, if you try to port it as is you will often suddenly see performance issues as you see the amount of data that has to be sent over the wire from the DB to your code tier.

[Kinrany]

This is a problem of SQL, not a database problem.