5 ms·
I second that. SPs/funcs have this weird tendency to always stay hidden in the fringes and out of sight, easily forgotten when adding new functionality, easily
by daneel_w 4y ago
I second that. SPs/funcs have this weird tendency to always stay hidden in the fringes and out of sight, easily forgotten when adding new functionality, easily overlooked when making changes elsewhere.
- KingOfCoders 4y agoFrom my experience only if there are dedicated DBAs and you have too many systems running - then you forget one. If you only have server code and the stored procedures in the same repository, with migrations, this problem goes away.
- maerF0x0 4y agoI believe that stems from people frequently not including them in version control, or not doing tests.
- daneel_w 4y agoWe version-control our SPs/funcs. We have unit tests, we have integration tests.
- simonw 4y agoI think stored procedures can be perfectly safe provides you follow these rules: - they live in source control - they are covered by automated tests - they are applied using some form of automatic database migration system (not by someone manually executing SQL against a database somewhere) If you don't have the discipline to do these things then they are likely best avoided.
- lukeramsden 4y ago> If you don't have the discipline to do these things then they are likely best avoided. I'd go further and say you should avoid databases and maybe even persistence entirely if you don't have the discipline to do the above. Sprocs will be the least of your problems otherwise.
- abledon 4y ago> they live in source control so that probably excludes 95% of legacy codebases out there from the 90s,00s
- tshaddox 4y agoAren’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 ago
- daneel_w 4y agoWe tick all the boxes. Please contain your arrogant presumptions.
- simonw 4y agoI was confused as to why you seemed to be taking offense here, then I realized that you posted the comment I was replying to. For "you" in my comment, please read "one" instead: > I think stored procedures can be perfectly safe provides one follows these rules: > ... > If one doesn't have the discipline to do these things then they are likely best avoided.
- CodeWriter23 4y ago> SPs/funcs have this weird tendency to always stay hidden in the fringes and out of sight, easily forgotten when adding new functionality, easily overlooked when making changes elsewhere. This is the classic "carpenter blames his tools for crappy results" argument. Implementation isn't easy.
- jb3689 4y agoSuch is the life of picking complex tools
- CodeWriter23 4y agoFor some people I suppose
- daneel_w 4y agoIt's not. You're just making guesses.
- CodeWriter23 4y agoIf the developer doesn't know / doesn't document the project has code embedded in the database, that's on the developer, not the tools. Because the use of any developer tools requires a certain level of competence in order to use them successfully.
- daneel_w 4y agoWe version-control all of it. Your assumptions don't matter for reality.