Восстанавливающие конфликты на хранимую процедуру, которая изменяет много

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, но не было никаких проблем, когда у нас был только один разработчик, ответственный за это. С помощью современного подхода разработчики в конечном итоге слишком долго проверяют друг друга, что должно быть в базе данных, а что не должно или они просто небрежны, а материал перезаписывается.

Есть ли лучший способ вставить необходимые записи в таблицу ProcessTypes, которая будет разрешаться при меньших конфликтах и ​​перезаписывается?

Одна вещь, о которой я могу думать, это иметь процедуру для каждого типа процесса, которая просто вставляет одну запись, но я уверен, что там есть лучшее решение.

Мы используем SSDT для управления схемой базы данных

Answer 1

У нас есть аналогичная проблема, у нас есть таблица, где нам нужно изменить достаточно много и другие разработчик изменения не совместимы. Ключ, чтобы получить изменения в основной Dev отрасли как можно скорее - я не знаю, что ваша стратегия ветвления, но у нас есть этот процесс:

• 1 - Создать ветку от разработчика
• 2 - Сделайте работу, проверить в филиале на
• 2а - Объединение с разработчика
• 3 - Слияние Dev (после кода обзора и т.д.)
• 4 - Слияние выпуска (после испытания и т.д.)

Когда мы сохраняем время между 1 и 3 как можно короче, и мы говорим другим разработчикам, что мы модифицируем таблицу, мы не видим никаких проблем.

2a интересно, чем дольше ваша ветка, тем больше вероятность, что вы столкнетесь с конфликтами, но если вы регулярно сливаетесь с dev на свою ветку, тем легче слить изменения.

Вместо прока мы используем слияния заявление на пост развертывания сборки, но код не проблема, это способ работы :)

Если по каким-то причинам вы не можете объединить ваши изменения легко я видел такие вещи, как дать каждому разработчику ряд чисел, которые они могут использовать, поэтому dev имеет 1-1000, 2 - 2000-2999 и т. д., но это не масштабируется для многих разработчиков.

Ред.