sql - 如何有效的版本存储程序？

Question

我是大型网上商店数据库开发团队的一员。我们使用 MS SQL 2016 和 ASP.NET。 SQL Server 由来自 10 多个 IIS 服务器的客户端使用，在生产环境中使用连接池(我们大约有 7-10k 批处理/秒)，并且我们使用 18 台 DEV/TESTING IIS 服务器(但只有一个 DEV 数据库，因为大小为多 TB)。我们开发了一项新功能，迫使我们经常更改现有的存储过程。

如果我们要将更改部署到生产环境，那么它是更改 IIS 应用程序修改和数据库过程更改的一部分。部署时，它们总是更改为 5 台 IIS 服务器，然后越来越多地更改为 5 台。同时，IIS 服务器上同时存在新旧版本。同时使用数据库中的过程时，这些版本必须共存一段时间。在数据库级别，我们通过使用过程的多个版本来解决这种情况。旧应用程序版本调用 EXEC dbo.GetProduct，新应用程序版本使用 dbo.GetProduct_v2。将新版本的应用程序部署到所有 IIS 后，每个人都在使用 dbo.GetProduct_v2。在下一次部署期间，情况将相反，dbo.GetProduct 将包含新版本。开发和测试环境也有类似的情况。

我完全意识到这个解决方案并不理想，我希望得到启发。

我们考虑将数据部分和逻辑部分分开。在一个数据库中将有数据表，其他数据库将仅包含过程和其他程序对象。当部署新版本时，我们只需部署包含逻辑的整个数据库的新版本，而无需创建程序的版本。逻辑数据库中的程序将查询数据库的数据。但是，该解决方案的缺点是无法使用我们计划明年使用的 native 编译过程，因为它们不支持在其他数据库中查询。

另一种选择是使用一个数据库并在不同模式中使用单独的过程版本...

如果您有任何想法、优点/缺点，或者您知道可以帮助我们管理/部署/使用多个过程版本的工具，请发表评论。

非常感谢

编辑:我们正在使用 TFS 和 Git，但这并不能解决 SQL 数据库中过程的版本控制问题。我的主要问题是如何处理使用数据库中的多个版本的程序来管理多个版本的 IIS 应用程序的需要。

Answer 1

使用 SSDT 或 SQL 比较和源代码控制可以轻松进行版本控制。部署也是如此。

您的问题不是版本控制。

您需要两个不同的存储过程，它们具有相同的名称，可能具有相同的参数，但代码不同，结果也可能不同。例如，在 .net 代码中更容易实现，因为您可以在一定程度上使用重载。

您的问题是使用不同代码的分阶段部署:
同一过程的两个版本必须共存。

就您而言，我会考虑使用同义词来掩盖实际的存储过程名称。

所以你有这些存储过程。

• dbo.GetProduct_v20170926(最新版本)
• dbo.GetProduct_v20171012(此版本)
• dbo.GetProduct_v20171025(下一版本)
• dbo.GetProduct_v20171113(后一)

那么你就有了

CREATE SYNONYMN dbo.GetProductBlue FOR dbo.GetProduct_v20171012;
CREATE SYNONYMN dbo.GetProductGreen FOR dbo.GetProduct_v20170926;

您的分阶段 IIS 部署引用其中一个 SYNONYMN

下一个版本...

DROP SYNONYMN dbo.GetProductBlue;
CREATE SYNONYMN dbo.GetProductBlue FOR dbo.GetProduct_v20171025;

然后

DROP SYNONYMN dbo.GetProductGreen;
CREATE SYNONYMN dbo.GetProductGreen FOR dbo.GetProduct_v20171113;

使用不同的架构会得到相同的结果，但最终会得到

- Blue.GetProduct
- Green.GetProduct

或者将您的发布日期编码到架构名称中。

- Codev20171025.GetProduct
- Codev20171113.GetProduct

即使您有另一组 IIS 服务器并在每组服务器上保留一个代码库，您也会遇到同样的问题:

基于blue/green deployment model