减少变化很大的存储过程的冲突

Question

我有一个名为 "populateProcessTypes" 的存储过程，看起来像这样

Insert Into ProcessTypes(processTypeId, processCode, processName)
Select processTypeId, processCode, processName
From
(
Select 1 processTypeId, 'L_EMP' processCode, 'Load Employees' processName UNION
Select 2 processTypeId, 'L_CC' processCode, 'Load Cost Centres' processName UNION
Select 3 processTypeId, 'L_SUP' processCode, 'Load Supervisors' processName UNION
Select 4 processTypeId, 'R_CHK' processCode, 'Run Validation Checks' processName UNION
Select 5 processTypeId, 'R_CLN' processCode, 'Run Data Checks' processName
)

由于越来越多的开发人员在他们自己的开发环境中创建新进程，我们经常会在合并到存储库时发生冲突或重要更改被覆盖。例如，一位开发人员将添加

Select 6 processTypeId, 'R_NEW' processCode, 'Run New Process 1' processName

另一个将添加

Select 6 processTypeId, 'R_OTH' processCode, 'Run Other Process' processName

另一个可能会重命名进程：

Select 2 processTypeId, 'L_CC' processCode, 'Load Cost Centre Hierarchy' processName

我对将数据加载到 ProcessTypes 的方式一直不满意 table 但是当我们只有一个开发人员负责时没有任何问题。使用当前的方法，开发人员最终会花费太长时间来相互检查数据库中应该有什么，不应该有什么，或者他们只是粗心大意，东西被覆盖了。

是否有更好的方法将所需的记录插入 ProcessTypes table，从而减少冲突和覆盖？

我能想到的一件事是为每个只插入一条记录的进程类型创建一个过程，但我确信那里有更好的解决方案。

我们使用 SSDT 来管理数据库模式

Answer 1

我们有一个类似的问题，我们有一个 table 需要进行大量更改，而其他开发人员的更改不兼容。关键是尽快将更改引入主开发分支——我不知道你的分支策略是什么，但我们有这个过程：

1 - 从 dev
2 - 工作，在分支机构签到
2a - 从开发合并
3 - 合并到开发（在代码审查等之后）
4 - 合并发布（测试后等）

当我们尽可能缩短 1 和 3 之间的时间并告诉其他开发人员我们正在修改 table 时，我们没有发现任何问题。

2a 很有趣，你的分支越长，你就越有可能发生冲突，但如果你经常从 dev 合并到你自己的分支，合并更改就越容易。

我们在 post 部署构建上使用合并语句而不是 proc 但代码不是问题，这是工作方式:)

如果出于某种原因您无法轻松合并您的更改，我看到过一些事情，比如给每个开发人员一个他们可以使用的数字范围，所以开发人员 a 有 1-1000，2 有 2000-2999 等等，但这不是'无法扩展到很多开发人员。

埃德

减少变化很大的存储过程的冲突

Reducing conflicts on stored procedure that changes a lot

database

stored-procedures

merge-conflict-resolution

sql-server-data-tools