Nope, I am assuming that you are using a proper RDMS with enterprise capabilities and not fad databases with lower quality tooling.
Oracle was just an example of what the minimum bar should be.
With Oracle you can also use C for the stored procedures if you are so much inclined, although I really wouldn't advocate for it.
As for logging in, it is a matter of permissions and policies.
Re:Code in Database vs. Code in Application
by somehnguy on Monday July 11, 2022 @10:08PM
(#32064755)
If embedding C functions into my database is the ‘right way’, well I’ll stick to the ‘wrong way’.
Apparently we have some reading comprehension problem => "...although I really wouldn't advocate for it.".
Re:Code in Database vs. Code in Application
by somehnguy on Tuesday July 12, 2022 @10:55AM
(#32070896)
I skimmed, sue me :)
It being available means people will do it, and I want nothing to do with that.
My team is unfortunately responsible for maintaining a legacy monstrosity of an app that uses thousand line stored procs. You’re kinda advocating for that as ‘right’. I’ll take a ‘fad’ database missing the ‘proper tooling’ to let people do such things any day.
What if instead we have to use Amazon Aurora or Azure cosmosdb …
you can’t simply use C for your stored procedure and you can’t simply login in the vm to have a debugger.