SQL переупорядочение приоритета построчно - PullRequest
1 голос
/ 09 ноября 2009

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

В моей таблице SQL есть 3 поля, которые влияют на мою проблему: «Приоритет» как реальное, Start_Date как дата и «Furnace_Name» как varchar (10). Когда пользователь добавляет элементы в таблицу (через приложение VB.net для Windows), он (и) указывает приоритет для заданной даты начала.

Если Item1 имеет приоритет 1 в указанной печи , то Item2 в той же печи может иметь приоритет 2 и ему будет присвоено значение Start_Date после элемента 1.

Но если Item2 присвоен приоритет 0.5 (или любое число меньше приоритета Item1), тогда его Start_Date будет раньше Start_Date элемента 1. Примечание. Пользователь может указать прим., Скажем, 3,75 или любое другое число. В соответствии с бизнес-правилами работа с PR 0.5 может быть перенесена вперед и завершена после работы с номером с более высоким приоритетом в той же печи.

После добавления каждого предмета я хочу просмотреть список предметов и обновить все приоритеты, чтобы они стали целыми числами, начиная с самой ранней даты начала_приятия с приоритетом = 1, затем 2, 3 и т. Д. Но в первый раз, когда я разместил этот вопрос, я не упомянул, что в каждой Печи происходит перенумерация Приоритетов, так что у каждой Печи может быть Prioirty 1, 2 и т. Д. Кроме того, указанная печь может иметь 1: n элементов с одинаковым приоритетом. После того, как я перенумерую эти Приоритеты в целые, элементы, которые начинаются с того же Приоритета, должны иметь тот же Приоритет.

Читатель предложил:

Update Table 
Set Priority = 
    (Select Count(*) 
     From table
     Where Start_Date <= T.Start_Date)   
     From Table T   
Where Start_Date > getDate()

Я улучшил это до:

Update tblTable
Set      Priority = 
 (Select Count(*) 
 From tblTable
 Where Start_Date <= T.Start_Date and
 Start_Date  >= @CutoffDate 
 and Furnace_Name = T.Furnace_Name
 )   
From tblTable T

Но это не совсем работает, потому что Приоритеты внутри печи начинаются не с 1. Может ли кто-нибудь объяснить мне лучший способ сделать это или подойти к проблеме?

Вот некоторые тестовые данные:

Sch_ID Furnace Start_Date Priority Желаемый приоритет после повторного заказа 372 1335 9.09.09 8:00 утра 1 1 380 1335 9.09.09 7:00 утра 1 1 314 1335 9.09.09 10:30 2 2 324 1335 9.09.09 10:00 2 2 235 1335 9.09.09 16:00 0.5 3 234 1335 9.09.09 16:00 0.5 3

403 1510 9.09.09 11:30 2 2 404 1510 11.09.09 11:30 2 2 402 1510 9.09.09 8:30 2 2 389 1510 9.09.09 7:30 1 1 390 1510 9.09.09 7:30 1 1 388 1510 9.09.09 7:00 1 1 374 1510 11.09.09 18:30 3,5 4 383 1510 11.09.09 17:30 3,5 4 385 1510 9.09.09 15:30 3 3 386 1510 9.09.09 13:30 3 3

Спасибо.

приписка

Причина, по которой мне нужно в первую очередь изменить нумерацию Приоритета Работы, заключается в том, что после применения бизнес-правил, относящихся к планированию Заданий, возможно (хотя и необычно), что их Приоритеты выходят из числового порядка. Например, наличие дублирования в другой печи может отодвинуть время начала текущей работы назад, заставив его быть позже в течение дня, чем задание с более высоким номером PR (и, следовательно, с более низким приоритетом).

Поскольку пользователь указывает относительную важность Работы в печи, указав PR, обязательно, чтобы мы перенумеровали Приоритеты после добавления каждой работы. Ситуация, описанная выше, когда задание с PR 2 находится между 2 заданиями с PR 1, не может произойти, хотя одновременно может быть запланировано 2 или более заданий с одинаковым приоритетом.

Я ценю вашу помощь. Можете ли вы сделать последний шаг?

Спасибо.

Ответы [ 3 ]

2 голосов
/ 09 ноября 2009
WITH    rows AS
        (
        SELECT  tt.*, DENSE_RANK() OVER (PARTITION BY Furnace_Name ORDER BY Priority) AS dr
        FROM    tblTable tt
        )
UPDATE  rows
SET     Priority = dr

Обновление 2:

Попробуйте это:

WITH    data (Sch_ID, Furnace, Start_Date, Priority, Pr) AS
        (
        SELECT 372, 1335, CAST('11/9/09 8:00 AM' AS DATETIME), 1, 1
        UNION ALL
        SELECT 380, 1335, '11/9/09 7:00 AM', 1, 1
        UNION ALL
        SELECT 314, 1335, '11/9/09 10:30 AM', 2, 2
        UNION ALL
        SELECT 324, 1335, '11/9/09 10:00 AM', 2, 2
        UNION ALL
        SELECT 235, 1335, '11/9/09 4:00 PM', 0.5, 3
        UNION ALL
        SELECT 234, 1335, '11/9/09 4:00 PM', 0.5, 3
        UNION ALL
        SELECT 403, 1510, '11/9/09 11:30 AM', 2, 2
        UNION ALL
        SELECT 404, 1510, '11/9/09 11:30 AM', 2, 2
        UNION ALL
        SELECT 402, 1510, '11/9/09 8:30 AM', 2, 2
        UNION ALL
        SELECT 389, 1510, '11/9/09 7:30 AM', 1, 1
        UNION ALL
        SELECT 390, 1510, '11/9/09 7:30 AM', 1, 1
        UNION ALL
        SELECT 388, 1510, '11/9/09 7:00 AM', 1, 1
        UNION ALL
        SELECT 374, 1510, '11/9/09 6:30 PM', 3.5, 4
        UNION ALL
        SELECT 383, 1510, '11/9/09 5:30 PM', 3.5, 4
        UNION ALL
        SELECT 385, 1510, '11/9/09 3:30 PM', 3, 3
        UNION ALL
        SELECT 386, 1510, '11/9/09 1:30 PM', 3, 3
        ),
        ranks AS
        (
        SELECT  *, DENSE_RANK() OVER (PARTITION BY Furnace ORDER BY CASE WHEN Priority = 0.5 THEN 1 ELSE 0 END, Priority) AS Dr
        FROM    data
        )
SELECT  *
FROM    Ranks
ORDER BY
        Furnace, Start_Date

Это зависит от того факта, что исходные приоритеты упорядочены так же, как и StartDate s.

Вы должны решить, что произойдет, если это не так. Скажите, как эти данные будут упорядочены?

Date   Priority 
07:00  1
08:00  2
09:00  1
10:00  2
2 голосов
/ 09 ноября 2009

Мне кажется, что главной проблемой здесь является базовая модель, которая усложняет эту задачу. Если бы вы рассмотрели изменение модели, большинство ваших проблем исчезло бы, например:

furnace_model_01
Я знаю, что это не совсем то, о чем вы просили, но в долгосрочной перспективе ...

ОБНОВЛЕНИЕ ПОСЛЕ КОММЕНТАРИИ :
Это должно позволить вам указать, кто запланировал что, когда и где.

furnace_model_02

1 голос
/ 09 ноября 2009

Мне кажется плохой идеей иметь поле, которое устанавливается как пользователем, так и полуавтоматическим алгоритмом приложением / базой данных. Разве вы не можете просто заказать на основе Start_Date и Priority, когда вы select из таблицы?

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...