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.
Exceptions are fancy returns. Everything else is fancy goto, including returns…
Honestly I think the idea of hundreds of tiny instances of Mastodon or Lemmy is not the way the fediverse should work. It probably won’t work that way because it doesn’t scale well. However, having a half-dozen or so large instances would give you almost the entire benefit without as many of the issues. Would Reddit be having a meltdown right now if there was even just one other instance of Reddit everyone could move to?
I think federation and centralization is the key to success.
I played the crap out this game as kid… abusing the track builder as much as possible.
Why is the solution to housing always tiny dense condos!