3 ms·

yeah, I don't think this is a problem with sprocs, per se. I think this is a problem because the database code is treated differently from the application code

yeah, I don't think this is a problem with sprocs, per se. I think this is a problem because the database code is treated differently from the application code, because so few coders understand SQL well enough to be comfortable in it. So, as you say, the DBA's tend to be autonomous, and held to different standards. And with less ability to say "we have tech debt, we need to refactor our sprocs" because of the knock-on effect on the application code. It's a management problem rather than a technical certainty, I think.

WJW 6y ago
If it happens consistently across "dozens to hundreds" of enterprise environments as stated by the GP and with apparently zero exceptions in which they remained simple then, while maybe not a technical certainty, it should be treated as a practical certainty. Pointing out that it's probably caused by management is not really very useful since there are so few means available for line workers to fix their managers.
- marcus_holmes 6y ago
  This is true, and I agree, but mis-attributing the problem is still not good. After all, if (for instance) a new IDE plugin appeared that managed sprocs consistently with code and solved this problem, then we'd still face "sprocs are bad" criticism because the problem was mis-attributed.