It's a very wierd concern for me. I have never liked that justification as we convert 1:1 SAS to python. If you use Django, converting it to flask is really hard. If you use postgresql, converting it to oracle is really hard.
I love stored procedures and triggers. Many of my colleagues don't understand why sticking everything on a database is a great idea. These are the same people who think that unique constraints are too much overhead. It's a great tool to use. Do you need CRUD stored procedures when sql alchemy exists? Nope. Do you need it when doing an extremely complex select with multiple joins that you want to run all the time? Maybe. Or allowing insert operations on base tables in a view. Or tracking and monitoring who does what. Also, you can back up stroed procedures to make updates easy.
Thanks,
Ben
On Wed, Apr 20, 2022, 4:48 PM Alex Aquino <alex@xxxxxxxxxxxxxxxxxx> wrote:
Agree on the lock in comment, however, can't we say that of anything one is dependent on in the tech stack, whether that be at the java vs _javascript_ vs python, or now aws vs azure vs gcp?Have always wondered that lock in concern seems to be only mentioned in light of dbs, but not any other piece of the tech stack.On Wed, Apr 20, 2022 at 3:31 PM Ravi Krishna <srkrishna@xxxxxxxxxxx> wrote:>I've really only ever worked in web development. 90+% of web
>developers regard doing anything at all clever in the database with suspicion.One common argument they use is that if you write your business logic in stored procedure, you are locked to that database since stored procedure languages are pretty much vendor locked.
TBH when one sees tens of thousands of Oracle PL/SQL code, there is some truth in this.
