是否应该编写一个冗长复杂的2000+行存储过程？
在我的特定情况下,此存储过程包含许多if/then,case,goto和branching语句.它的工作原理是根据查询的输入和结果构造SQL查询,并使用execute语句来运行构造的查询.它可以在一次调用中执行多个构造的查询,并使用这些查询的结果来构造要运行的其他查询.
它非常混乱,难以理解.调试很困难,知道发生了什么的唯一方法是通过调用来查看它正在做什么.几乎没有任何异常处理或记录.保持它是一种痛苦.事实上,没有人真正知道它的作用或它是如何创造的,如果我们不得不对其进行修改,我们就必须采取"交叉指责并希望获得最佳"的方法.但是,我认为出于性能原因这样做了.
许多应用程序都使用此过程.我能想到做这样的事情的另一种方式是通过网络服务.它可能在复杂性方面具有可比性,但更容易理解.但是,它可能会慢几倍,因为它仍然需要为1个请求多次调用数据库.
那么,我的问题是,我们如何决定何时何时不写长存储过程？
有什么我缺少或我们只是忍受我们的怪物存储过程？
有没有办法将存储过程构建并分解为更小的组件,以便于理解？
当您需要对数据库进行多次调用时,存储过程总是比其他任何东西都快吗？
我不确定为单个函数编写2000+ LOC是一个好主意.我最初的反应是说你的sproc应该分解成更小的函数(表值或标量,适当的)和存储过程(用于非查询操作).然而,这可能只是移动LOC而不是简化实际操作.遗憾的是,如果没有发布任何源代码,就很难提供更具体的建议.
听起来你需要改变编写和维护这个存储过程的方式.
从SQL查询创建存储过程.也许你可以编写一个应用程序/脚本来生成SQL来创建/更新你的存储过程.
这样做可以为您提供可重用存储过程的所有好处(您已有的好处),但它可以使存储过程的维护更容易.
通过拥有2000多行存储过程,您基本上可以将自己锁定为唯一可以完成工作的人.这意味着你陷入了困境,无法前进(没有职位晋升,没有新项目的任务等).
| 归档时间： |
|
| 查看次数： |
1725 次 |
| 最近记录： |