Stored procedures 何时编写长存储过程

关于什么时候应该和不应该编写一个长而复杂的2000+行存储过程，有什么指导方针吗

在我的例子中，这个存储过程包含很多if/then、case、goto和分支语句。它根据查询的输入和结果构造SQL查询，并使用execute语句运行构造的查询。它可以在一个调用中执行多个构造的查询，并使用这些查询的结果构造其他要运行的查询

这是相当混乱和难以理解的。调试是很困难的，知道正在发生什么的唯一方法是通过一个调用查看它在做什么。几乎没有任何异常处理或日志记录。维持它是一种痛苦。事实上，没有人真正知道它是做什么的，或者它是如何创建的，如果我们必须对它进行修改，我们将不得不采取“祈祷并希望得到最好的”方法。但是，我认为这样做是出于性能原因

许多应用程序都使用此过程。我唯一能想到的另一种方法是通过web服务来完成类似的事情。它的复杂程度可能相当，但更容易理解。但是，它的速度可能会慢很多倍，因为对于1个请求，它仍然需要多次调用数据库

所以，我的问题是，我们如何决定何时以及何时不编写长存储过程

是我遗漏了什么，还是我们必须忍受我们庞大的存储过程

是否有方法将存储过程结构化并分解为更小的组件，以便易于理解

---

当您需要对数据库进行多次调用时，存储过程是否总是比任何其他方法都快，并且是正确的选择？

我不确定为单个函数编写2000+LOC是否是一个好主意。我最初的反应是，存储过程应该分解为更小的函数（表值或标量，无论什么合适）和存储过程（用于非查询操作）。然而，这可能只是移动LOC，而不是简化实际操作。不幸的是，如果没有发布任何源代码，就很难给出更具体的建议。

听起来您需要更改编写和维护此存储过程的方式

存储过程是从SQL查询创建的。也许您可以编写一个应用程序/脚本来生成SQL以创建/更新存储过程

这样做会给您带来可重用存储过程的所有好处（您已经拥有的好处），但它会使存储过程的维护变得更容易

---

通过使用2000+行存储过程，您基本上将自己锁定为唯一可以完成此工作的人。这意味着您被困在原地，无法继续前进（没有职位提升，没有新项目的任务分配等）。

如果您仍然存在此问题，您可以尝试使用一些CLR（公共语言运行时集成），它正在使用一些其他microsoft语言，如C#、visual basic等来编写解决方案。这将有助于代码的调试和维护。

谢谢，这正是我希望得到的评论类型。发布2000多行可能有点多，我怀疑我的公司是否会感谢我发布代码的任何部分。我知道使用视图或函数会有什么帮助，但问题是它会根据其他查询的结果动态创建查询。这可能会成为我们必须做的许多狂欢、观点和功能。一个词：永远！你不应该写这样一个怪物。。。。任何函数/过程的长度都不应超过两页，在这一问题上采取了非常开放的立场。。。。150行-单个过程中最多2000行代码….-多么糟糕的维护工作@dtc-嘿，我想知道你是否/如何解决了巨大的程序问题。我感觉到你的痛苦。我有一个1550 LOC程序，我现在有一个手柄，但在早期，它是一个需要学习/理解的野兽。我在想，这件事怎么可能/应该被打破。