如何使用同一数据库处理来自多个应用程序的存储过程代码更改？

Question

我们环境中的数据库由 2 个不同的环境/应用程序共享。 在这 2 个应用程序中，第一个应用程序 A 会经常更新，而第二个应用程序 B 不会经常更新。

所以这里的情况是，当应用程序 A 使用新代码（主要是存储过程）进行更新时，它有时会影响和破坏第二个应用程序 B，该应用程序正在由另一个团队更新，并且更新不频繁。 我知道这不应该是处理它的正确方法，不同时更新两个环境可能是灾难性的。 发生这种情况是因为应用程序 A 和 B 由不同的团队处理。

你会如何优雅地处理这种情况？

从应用程序 B 中，我可以采取的预防措施是 - 在代码中检索数据 - 检索数据时最好的方法是检查空白/空列，这样如果应用程序 A 添加了新列，应用程序 B 可以忽略它们。 在 SQL 中检索数据 - 在过程中，可以使用可选参数来处理。

但是当 C# 代码调用一个过程时，我们应该传递参数值，如果添加了新参数，那么它就会中断。 有没有办法确保如果缺少调用参数，则应该忽略它（来自 C# 或 SQL Server）？

我的研究表明 -

1. 我可以先从存储过程中检索参数列表，然后使用该列表调用过程以循环并检查参数是否存在。 这样即使应用 A 添加了新的参数，也可以由应用 B 自动处理。 这可以使用 C# 中的 DeriveParameters 或 SQL 查询来获取参数列表。

2. 更改所有 SPROC 以采用 CSV 格式的参数。并在 SPROC 中拆分它们并相应地使用它。 对于数百个现有的存储过程来说，这听起来很糟糕。

再次，正如我所说 - 这看起来不是一个好的解决方案，如果你有类似的情况，你会有什么不同的处理方式？ 是否有一个框架，我不知道哪个可以解决这种情况？

环境 - ASP.NET/C# 4.0，SQL Server 2008 R2

编辑 - 让我在这里重新表述并提供更多细节。

1. 应用程序/团队 A 更改了代码，但只有 C# 代码被推出到生产中，而不是 DB 更改。 这就是区别所在。并且数据库代码只会在下一个版本中使用。

2. 应用程序/团队 B 拥有最新代码，但数据库更改尚未投入生产，仍使用旧数据库。

Answer 1

我不相信有一个优雅的解决方案，但是，由于您无法重写整个应用程序，所以...对于您的场景，我会复制所有应用程序的 SP 并将它们放在单独的架构中。

在您的数据库中创建不同的用户，并让每个应用程序使用自己的用户连接到数据库。应用程序 A 的 DB 用户，它的角色，不应该有执行属于其他模式的 SP 的权限，对于应用程序 B 的 DB 用户也是如此。

当然，您需要重写应用程序的一些代码来更改连接字符串。

Answer 2

也许每个应用程序都可以有自己的一组存储过程，儿子他们不会互相打扰。

Answer 3

是否有不能为新参数分配默认值的原因？例如

CREATE PROCEDURE xxx

   @OldParam   int
  ,@NewParam   int  = 0

AS

   <etc>

应用程序“A”传入两个参数。

应用程序“B”是在 proc 只有一个参数时编写的，并且只使用一个重要的参数调用它。在新版本中，第二个参数将不被传递，因此它采用默认值 0... 并且对过程进行了适当的编码。 （NULL 或特殊的默认值可用于“标记”来自旧系统的调用。）

---

[添加]

一个可能的长期解决方案是向数据库添加某种版本系统，每次数据库更新时都会更新。

• 当应用程序启动时，它会获取当前版本

• 如果有不同版本的参数不同的调用，你在调用的时候适当检查和格式化，比如

  如果版本

  使用 2 个参数调用 proc

随着时间的推移，跟踪和维护这将是繁琐和混乱的，但如果您不能同时更新所有系统（A、B 和数据库），那么您的选择就会受到限制。