Put the business logic into the database. Use @JavaOOQ to access it. Works like a charm and the performance will be better because less data is transferred from the database to the app.
I've always found it very weird that some people seem to categorically reject stored procedures, as if they were inherently bad, instead of just a tradeoff like everything else.
5
3
3
13
There are so many "it depends" here. While I understand the sentiment i struggle to imagine this as a default way to implement complex systems especially ones that interact with other systems.
2
4
It depends on the type. If we look at data centric applications like EPR or CRM systems this works very well. In my current project we have 2000 database tables and around 4000 stored procedures.
1
1
Thats what I mean. Most applications I've worked with past years were not that database heavy. On the other hand there was a lot of interactions with other systems or managed services. Mixing logic between db and other places in such case I'm afraid would be terribly messy
2
3
You seem to think the db is somehow different from your categorisation of "other systems" or "managed services". You already have a terribly messy set of interactions, it doesn't matter if you allow for the db to be seen as yet another service. In fact, it would help.
2
1
Yet, a lot of people call it "db" and not "service", and thus treat it as special, arcane, and dangerous (?). Why is that?
1
2
Exploring the reasons could be interesting. How many of them were architectural or commercial? How many of them were related to the programming language(s) used? How many were just related to bad code/bad usage patterns? Could we address them differently today?
Nov 5, 2020 · 9:50 AM UTC
1
6
