3 ms·
> stored procedures and coupling Right. Funny how 'best practice' became to use stored procs rather than generated queries. Partly because it constrains and de
by redcalx 11y ago
> stored procedures and coupling
Right. Funny how 'best practice' became to use stored procs rather than generated queries. Partly because it constrains and defines the API exposed by the DB and greatly helps avoid SQL injection issues. Those things can also be achieved with a well written code layer, and as for the 'API', well, we have so many stored procs that that argument has become somewhat tenuous.
There's the performance aspect as well - having the DBA know what queries will be 'thrown' at the server. But again, it's not black and white, it's more that the stored proc does tend to limit really bad SQL queries moreso that open ended srting queries, but 'it depends'.
- batou 11y agoRather than write another reply, I'll link you to my thoughts: https://news.ycombinator.com/item?id=9928688 https://news.ycombinator.com/item?id=9928688
- redcalx 11y agoNice reference discussion, thanks. Sounds like we're on the same wavelength. Our main issue (IMO) is that if you get a SQL Server person in to solve SQL Server performance issues then you're likely going to go down the route of one massive all powerful SQL Server box which just compounds the problem. A broader solution of moving away from pure SQLServer and towards distributed work, caching layers, etc. is probably a saner long term path to take. But in business short term thinking generally takes precedence over long term.
- batou 11y agoThat's very true which is why we wrangled the architecture off the database folk :)