编写长存储过程是否是数据库设计和编码风格不好的标志？

Question

我遇到过一个声称已在Sql Server中写过5000行存储过程的人。这个长存储过程实际上是否需要？或者它是一个糟糕的数据库和编码设计的标志？我真的很担心在我的一个基于保险的实时项目中，我从未在存储过程中写过100行代码，这些项目必须处理美国Acords和Supplements。顺便说一下，他吹嘘自己好像写了这么久的存储过程做得很好。

提前致谢：）

等待你的回复。

Answer 1

从我个人的经验来看，有几个条件会迫使你写出如此长的存储过程，这些是我现在记得的2个

• 错误的数据库设计（如您所述）
• 计算非常复杂，报告等的一个很复杂的公式（例如人力资源 - 休假管理）

我不认为编写这么长的存储过程是件好事，我个人认为这是一件非常糟糕的事情，它表明数据库搞砸了，计划不够透彻。

Answer 2

我不认为存储过程的长度是不良设计或编码风格的标志。

我认为存储过程中的代码是糟糕的设计或编码风格的标志。

他本可以写

SELECT
*
FROM
TABLE
AS
t

这可能会很快增长，因为你知道这可能适合一条线，也许他认为它更具可读性。

关键是，我不认为长度是确定一个是好还是坏的好指标。你可以编写一个比5000行sproc差的100行sproc。

如果我个人正在看我全新的5000系列sproc，我会担心而不是自豪，即使别无选择。保持这将是一场噩梦。

但是在你的朋友的情况下，如果不知道sproc执行什么动作或者它是如何做的话，很难以任何方式评论。