是否有关于何时应该和不应编写长而复杂的 2000 多行存储过程的指导方针？
在我的特定情况下，这个存储过程包含很多 if/then、case、goto 和分支语句。它的工作原理是根据查询的输入和结果构造 SQL 查询，并使用执行语句来运行构造的查询。它可以在一次调用中执行多个构造的查询，并使用这些查询的结果来构造其他要运行的查询。
它非常困惑且难以理解。调试很困难，了解正在发生的事情的唯一方法是单步执行调用以查看其正在执行的操作。几乎没有任何异常处理或日志记录。维护它是一种痛苦。事实上，没有人真正知道它做什么或它是如何创建的，如果我们必须对其进行修改，我们将不得不采取“交叉手指并希望最好”的方法。但是，我认为这是出于性能原因这样做的。
许多应用程序都使用此过程。我能想到做这样的事情的唯一另一种方法是通过网络服务。它的复杂性可能相当，但更容易理解。但是，它可能会慢很多倍，因为它仍然需要为 1 个请求多次调用数据库。
所以，我的问题是，我们如何决定何时以及何时不编写长存储过程？
是不是我遗漏了什么，或者我们是否只需要忍受我们可怕的存储过程？
有没有办法将存储过程构建和分解成更小的组件，以便它们易于理解？
当您需要对数据库进行多次调用时，存储过程是否总是比其他任何东西都快并且是正确的选择？
最佳答案
我不确定为单个函数编写 2000 多个 LOC 是否是个好主意。我最初的 react 是说你的 sproc 应该被分解成更小的函数(表值或标量，任何合适的)和存储过程(用于非查询操作)。然而，这可能只是移动 LOC 而不是简化实际操作。不幸的是，如果没有发布任何源代码，就很难给出更具体的建议。
关于stored-procedures - 何时编写长存储过程，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/6336044/