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

Question

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

预先感谢:)

等待您的回复。

Answer 1

根据我个人的经验，有几个条件迫使你编写这么长的存储过程，这是我现在记得的两个条件

• 糟糕的数据库设计（正如你已经提到的）
• 一个非常复杂的计算公式非常复杂，报告等（例如人力资源 - 休假管理）

我不认为编写这么长的存储过程是一件好事，我个人认为这是一件很糟糕的事情，它表明数据库被搞乱了，计划不够周密。

Answer 2

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

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

他本可以写

SELECT
*
FROM
TABLE
AS
t

“那可以增长得很快，正如你知道的那样，可以放在一行中，也许他认为它更具可读性”。

重点是，我不认为长度是确定存储过程好坏的一个很好的指标。您可能会编写一个 100 行存储过程，但它比 5000 行存储过程要差。

如果我个人正在查看我的全新 5000 线存储过程，即使没有其他选择，我也会感到担忧而不是自豪。维持这一点将是一场噩梦。

但在您朋友的情况下，如果不知道存储过程执行什么操作或如何执行操作，就很难以任何方式进行评论。