SQL Сервер: использование хранимых процедур для динамического изменения последовательности заказов в зависимости от определенных условий - PullRequest
0 голосов
/ 19 июня 2020

У меня есть таблица, которая создается через INSERT INTO из представления. Данные выглядят так:

Priority    ID  Status
1   108999_1_S010   Planned
1   108999_1_S020   Planned
1   108996_1_S030   Planned
1   108996_1_S035   Planned
1   108996_1_S040   Planned
1   108996_1_S050   Planned
1   108996_1_S060   Planned
1   108996_1_S070   Planned
1   108996_1_S080   Planned
1   108996_1_S090   Planned
1   108996_1_S100   Planned
1   108996_1_S110   Planned
1   108996_1_S120   Planned
2   108999_2_S010   Planned
2   108999_2_S020   Planned
2   108996_2_S030   Planned
2   108996_2_S035   Planned
2   108996_2_S040   Planned
2   108996_2_S050   Planned
2   108996_2_S060   Planned
2   108996_2_S070   Planned
2   108996_2_S080   Planned
2   108996_2_S090   Planned
2   108996_2_S100   Planned
2   108996_2_S110   Planned
2   108996_2_S120   Planned
3   108999_3_S010   Planned
3   108999_3_S020   Planned
3   108996_3_S030   Planned
3   108996_3_S035   Planned
3   108996_3_S040   Planned
3   108996_3_S050   Planned
3   108996_3_S060   Planned
3   108996_3_S070   Planned
3   108996_3_S080   Planned
3   108996_3_S090   Planned
3   108996_3_S100   Planned
3   108996_3_S110   Planned
3   108996_3_S120   Planned
4   108999_4_S010   Planned
4   108999_4_S020   Planned
4   108996_4_S030   Planned
4   108996_4_S035   Planned
4   108996_4_S040   Planned
4   108996_4_S050   Planned
4   108996_4_S060   Planned
4   108996_4_S070   Planned
4   108996_4_S080   Planned
4   108996_4_S090   Planned
4   108996_4_S100   Planned
4   108996_4_S110   Planned
4   108996_4_S120   Planned
5   110225_1_S010   Planned
5   110225_1_S020   Planned
5   110224_1_S030   Planned
5   110224_1_S035   Planned
5   110224_1_S040   Planned
5   110224_1_S050   Planned
5   110224_1_S060   Planned
5   110224_1_S070   Planned
5   110224_1_S080   Planned
5   110224_1_S090   Planned
5   110224_1_S100   Planned
5   110224_1_S110   Planned
5   110224_1_S120   Planned

Priority создается при вставке с использованием функции ROW_NUMBER() в представлении. Как видно из столбца ID, существует 14 подстанций для любого заданного порядка, поэтому будет четырнадцать эквивалентных номеров для каждого приоритета. Это все хорошо, но эта таблица постоянно обновляется через PowerApps и Power Automate. У меня есть два требования к этой таблице:

  • Если новый набор заказов поступает из базового исходного представления и их priority, например, 3, то мне понадобится текущий заказы с priority (3, 4, 5) для всех сменяют один на (4, 5, 6).
  • Если столбец status определенного ID изменяется с «Планируется» на « Завершено », тогда Priority в этой строке становится 0, и следующий Priority заказ для этой станции переходит в эту позицию. (Например, если заказ с ID «108996_2_S030» (который имеет priority 2) завершен, то priority этого заказа становится 0, а заказ «108996_3_S030» становится 2. И все последующие заказы становятся Priority - 1.

Я думаю, мне нужны две отдельные хранимые процедуры для этого. Запускается при вставке из представления и при изменении столбца status. Однако я не уверен, как напишите их, чтобы они не мешали друг другу.

Первоначально я собирался просто пересчитывать priority полностью каждый раз, когда один из этих триггеров, но предостережение в том, что мы также должны иметь возможность вручную измените priority через PowerAppss, поэтому я не хочу сбрасывать эти изменения.

Кто-нибудь знает, как я могу написать хранимые процедуры, которые дадут мне результат?

1 Ответ

0 голосов
/ 20 июня 2020

Итак, вот что у меня есть на данный момент:

SELECT 
       ROW_NUMBER() OVER (PARTITION BY [Workstation] ORDER BY [Ship Date], [RootID], [Workstation]) as Priority
      ,bm.[Customer]
      ,[ProductionOrder]
      ,[RootID]
      ,[SalesOrder]
      ,[Line]
      ,[QtyID]
      ,[TotalQty]
      ,[Material]
      ,[Config]
      ,[Description]
      ,[Workstation]
      ,[ConfigGroup]
      ,[Business Unit]
      ,[StartDate]
      ,[FinishDate]
      ,[ShipDate]
INTO #OrderInsert
FROM 
[BoomsBuildMaster] as bm
INNER JOIN
[BoomsBuildScheduleTEST] as bs
ON bm.RootID = bs.[Sales Order] + '_' + bs.[Line No]
WHERE bm.ProductionOrder NOT IN (SELECT [ProductionOrder] FROM [BoomsBuilder])
AND bs.Status = 'Ready'

UPDATE [BoomsBuilder]
SET Priority = Priority + (SELECT (MAX(Priority) - MIN(Priority) + 1) FROM #OrderInsert)
WHERE Priority >= (SELECT MIN(Priority) FROM #OrderInsert)

INSERT INTO [BoomsBuilder]
(
       [Priority]
      ,[Customer]
      ,[ProductionOrder]
      ,[RootID]
      ,[SalesOrder]
      ,[Line]
      ,[QtyID]
      ,[TotalQty]
      ,[Material]
      ,[Config]
      ,[Description]
      ,[Workstation]
      ,[ConfigGroup]
      ,[Business Unit]
      ,[StartDate]
      ,[FinishDate]
      ,[ShipDate]
)
SELECT * FROM #OrderInsert;

Что здесь происходит: эта хранимая процедура срабатывает, когда таблица [BoomsBuildScheduleTEST] обновляет строку до Status «готово».

Допустим, одновременно введены три новых заказа с приоритетами (5, 6, 7). Затем текущие (5, 6, 7) заказы будут перемещены в (8, 9, 10), а все, что после этого, будет перемещено в (11, 12, 13 ...). И тогда будет вставлен новый (5, 6, 7).

Это будет работать для одного вставляемого заказа или даже для нескольких заказов, которые имеют последовательный приоритет. ОДНАКО, это не сработает, если, например, добавлены два новых заказа и приоритеты равны (3,7) соответственно. Не знаю, что делать в таком случае.

...