存储过程的版本更改

Question

我有一个非常依赖存储过程的应用程序(SQL 2005/2008).我们正在做一个小修改,修改这些存储过程中的25-35个.该应用程序使得两个版本的存储过程都必须可用.

这是应用程序的主要版本4,通常我们已经能够完全修改数据结构以适应每个新版本.但是在这种情况下,我们不能这样做.

以下是我提出的两个选项

1. 为每个存储过程创建一个"2"版本.如果我有一个名为getUser的过程,请创建一个getUser2.这样做的缺点是,每个版本更改时,存储过程的数量将呈指数级增长

2. 将@version参数添加到默认为v1的每个存储过程.这将使存储过程的数量减少,但会使每个存储过程膨胀

有没有人对此有任何想法？还有其他聪明的想法吗？

科迪

Answer 1

我借此机会从存储过程转移到ORM或其他方法.您提出的两种解决方案都需要某种代码更改来决定使用哪种存储过程.相反,我决定是使用存储过程还是ORM.我还会制定逐步淘汰大部分存储过程的计划.

在我的职业生涯中,我已经看到了很多糟糕的代码并搞砸了系统,但没有什么可以破坏我希望项目可以像GetItemFromLots_2_Temp_2在存储过程列表中看到的那样被抢救.与多个存储过程相比,多种方法更漂亮,更易于维护.

(对于喜欢存储过程的其他人.我不是说他们很糟糕.我确信有一些聪明的方法可以使用存储过程来处理这类事情,但是,如果使用这种方法,这个问题就不会有人问过.)

Answer 2

我肯定不会创建两个不同的文件。

也许在源代码管理中，您应该为所有版本创建一个分支，然后为下一个版本创建一个新分支，然后您可以将这两个分支作为单独的文件夹包含在系统上，并使业务逻辑指向正确的位置。

这个解决方案可能有点草率，但我认为这是几个弊端中较小的一个。

无论如何，在我看来，对存储过程代码进行实际版本控制是绝对必要的。