У нас есть таблица, настроенная следующим образом:
|ID|EmployeeID|Date |Category |Hours|
|1 |1 |1/1/2010 |Vacation Earned|2.0 |
|2 |2 |2/12/2010|Vacation Earned|3.0 |
|3 |1 |2/4/2010 |Vacation Used |1.0 |
|4 |2 |5/18/2010|Vacation Earned|2.0 |
|5 |2 |7/23/2010|Vacation Used |4.0 |
Бизнес-правила:
- Баланс отпуска рассчитывается по заработанным отпускам за вычетом использованного отпуска.
- Используемый отпуск всегда применяется к сумме заработанной суммы за самый старый отпуск.
Нам нужно вернуть строки для заработанных отпусков, которые не были компенсированы использованными отпусками. Если использованный отпуск только компенсирует часть заработанной записи, нам нужно вернуть эту запись, показывающую разницу. Например, используя приведенную выше таблицу, набор результатов будет выглядеть следующим образом:
|ID|EmployeeID|Date |Category |Hours|
|1 |1 |1/1/2010 |Vacation Earned|1.0 |
|4 |2 |5/18/2010|Vacation Earned|1.0 |
Обратите внимание, что запись 2 была исключена, поскольку она была полностью смещена на использованное время, но записи 1 и 4 использовались только частично, поэтому они были рассчитаны и возвращены как таковые.
Единственный способ, которым мы подумали сделать это, - записать все записи, заработанные на отпуске, во временную таблицу. Затем получите общее количество использованных каникул и переберите временную таблицу, удалив самую старую запись и вычтя это значение из общего количества использованных каникул, пока общее количество использованных каникул не станет равным нулю. Мы могли бы привести это в порядок, когда оставшиеся каникулы использовались только в качестве старейшего отчета о заработанных каникулах. Это оставило бы нас только с выдающимися отчетами заработанных каникул.
Это работает, но очень неэффективно и плохо работает. Кроме того, производительность будет со временем ухудшаться по мере добавления большего количества записей.
Есть какие-нибудь предложения по лучшему решению, предпочтительнее на основе набора? Если нет, мы просто должны пойти с этим.
РЕДАКТИРОВАТЬ: Это база данных поставщиков. Мы никак не можем изменить структуру таблицы.