Direct queries and ORM. A stored procedure doesn’t provide much value as a unit of abstraction that couldn’t just exist in the code.
Direct queries and ORM. A stored procedure doesn’t provide much value as a unit of abstraction that couldn’t just exist in the code.
If anything, it separates code from the data more as far as I can tell, so maybe I’m missing something?
Stored procedures are code – so you’re putting code in the database. How do you test that code? How do you source control that code? How do you roll back that code to the previous version or compare it to a previous version? How to know the history of that code? If that procedure is designed to work in together with application changes, how to test and deploy those together? This is all not impossible but it’s certainly more difficult and creates more potential failure points.
Also, if something is somewhat data driven and there’s a bug, you simply alter a procedure versus doing a build and deploy of the entire application.
That’s the problem. You write like that like it’s an advantage but you’re literally editing code live in production.
The performance advantages of stored procedures are unsupported. Most database engines do not treat stored procedures any differently than regular queries. And it’s not that stored procedures aren’t optimized, it’s that queries are equally optimized.
Fortune 250 on down has used stored procedures with applications and it seems extremely clean and performance-oriented.
A lot of these companies also still use COBOL on mainframes (something I’ve actually worked on and don’t recommend either). Stored procedures made a lot more sense historically when SQL might actually have more expressive power than your programming language and when database interfaces were much complicated and non-standard.
I use Windows 11 – mildly modified – StartAllBack for a proper start menu and taskbar experience. I have it pretty much exactly as I want it without any annoyances.
I’m perfectly comfortable with Linux but I feel the same as you about using it on the desktop for all the same reasons.
This my hot take: Do not use stored procedures with applications. Keep your data separate from your code.
In my family, everyone else has an iPhone and I have Samsung S23. So I can maybe give both perspectives. If you just want a phone to be a phone, it’s hard to go wrong with an iPhone. It’s always the best default choice. That being said, I personally can’t go back to an iPhone. Lots of people recommend Google devices because of the “stock” Android experience but I greatly prefer the interface, integration, and customization of Samsung devices.
Anyway, in no particular order why I like Android/Samsung:
I can probably think of more but that’s a good start.
Why is the solution to housing always tiny dense condos!