I agree to an extent and in my current project have been making heavy use of PL/SQL to handle a lot of data logic having come off a project that tried to use En

I agree to an extent and in my current project have been making heavy use of PL/SQL to handle a lot of data logic having come off a project that tried to use Entity Framework to achieve the same thing. PL/SQL, for all its problems, does make it pretty straightforward to write a data API - AddX, AddYToX, AssociateXAndZ. It provides a nice abstraction over whatever table structure you may have and also makes it very clear, especially in the case of Table per Hierarchy type structures, what fields are required in what cases. The key thing is to limit yourself to what the language is good at - reading and writing data. You shouldn't need to do things like string manipulation, date conversions etc - that is what the calling code is responsible for doing. For me it makes sense to associate the data with the logic specifically relating to it as frontends can come and go without the underlying structure changing.