3 ms·
Aren’t those also the absolute bare minimum bar for any code in a production system?
by tshaddox 4y ago
Aren’t those also the absolute bare minimum bar for any code in a production system?
- simonw 4y agoYeah, I think so. But my hunch is that the majority of people who tell you never to use stored procedures have been burned by these techniques not being used for them.
- ThePadawan 4y agoThe realization that database procedures are code, not data, even though they reside on the database (where the data lives) is the difficult part.
- tshaddox 4y agoThat’s baffling to me. Who doesn’t realize that that thing which looks and behaves exactly like all other code isn't code?
- ttfkam 4y agoThe folks who treat databases as "that thing behind the ORM."
- ThePadawan 4y agoIt's a common thing to miss. There's a reason SQL injections are (unless things have changed recently) among the most prevalent classes of web exploits.
- simonw 4y agoBefore the development of decent migration systems it was incredibly common for database structure - including stored procedures - to be treated independently of source code in a repository.
- tshaddox 4y agoTrue, of course. There were also undoubtedly a lot of production systems that didn’t even use version control for non-database code. Industry practices certainly evolve over time. But it’s difficult to imagine a scenario where a team is aware of version control, uses it for the things they realize are code, but somehow doesn’t realize that stored procedures are code.
- tormeh 4y agoI know a place that operated like this for years, so I don’t have to imagine.
- tstrimple 4y agoThese sorts of places also tend to have database admins in one team and programmers in another team. All database changes go through the database team with tickets or whatever. It's a huge pain in the ass to navigate and enable quick changes.