Я пытаюсь создать запрос SELECT, который изменит некоторые даты в подмножестве записей " активность " для каждого человека в таблице данных.
Каждый человек идентифицируется уникальным образом с помощью «PersonID», а затем каждая запись активности с использованием «RecordID».
В каждом подмножестве записей действий, которые есть у человека, также будут даты против полей «Дата начала» и «Дата окончания».
Например, такие данные (отсортированные по дате начала, затем по наибольшей продолжительности):
(я добавил желтые полосы, чтобы дать представление о некоторых совпадениях и промежутках между наборами дат).
Там, где я работаю, у нас есть задача, которая включает в себя добавление максимум 1 " претензии " для связи с каждой из этих записей активности. Записи претензий имеют свои собственные даты начала и окончания, но каждая запись претензии должна:
- Не распространяется на продолжительность вне даты начала и окончания записи активности, к которой она прикреплена.
- Не перекрывается с продолжительностью любой другой записи претензии в подмножестве записей претензий данного лица
- Продолжительность не менее 1 месяца, определяемая как: начиная с первого дня месяца и заканчивая последним днем месяца (например, с 12 января по 31 декабря 2008 года), или начиная с через месяц, но заканчивается в другом месяце (например, с 31 декабря по 01 января 2009 года).
Это потому, что записи претензий проверяются по записям операций (с помощью внешнего инструмента проверки мы не можем его контролировать).
Таким образом, на основе приведенного выше примера запрос может выводить следующий эффективный набор дат для каждой записи операции для использования в качестве записей заявки:
Краткое описание того, что произойдет с каждой записью:
Запись 1 : Для записи претензии 1 использовались исходные даты из записей операций, т. Е. Создавалась запись заявки, охватывающая всю
период активности. При работе с записями в порядке сортировки
описанный, имеет смысл, что он просто требует полной активности
период для первой записи претензии для подмножества деятельности каждого человека
записи.
Запись 2 : Для записи заявки 2 были предоставлены NULL s, так как нет срока для подачи заявки на эту деятельность, которая еще не была заявлена
в записи 1.
Запись 3 : Для записи заявки 3 дата начала была установлена на 1/12/2018, потому что это самая ранняя дата подачи заявки,
как в течение этого периода активности, так и после последнего месяца последнего
претензия (т.е. дата окончания записи 1 25/11/2019).
Дата окончания была установлена на 31/12/2018. Вы можете спросить, почему это не так?
установить исходную дату окончания действия 23/1/2019. Если вы посмотрите
вперед до записи 5, установка даты окончания записи 3 на 23/1/2019 будет означать
установка даты начала записи 5 на 1/2/2019, и ее дата окончания будет
2/4/2019, что недостаточно для предъявления претензии. Так было бы
более эффективно остановить запись 3 в декабре, поэтому запись 5 может требовать как
Январь и февраль. Это может быть трудно для сценария, хотя!
Запись 4 : Для записи заявки 4 было предоставлено NULL s, так как нет срока для подачи заявки на эту деятельность, которая еще не была заявлена
в предыдущих записях претензий.
Запись 5 : Для записи претензии 5 дата начала была установлена на 01.01.2009. Для объяснения причины см. Запись 3.
Запись 6 : Для записи претензии 6 использовались исходные даты из записей операций. Это было только для иллюстрации того, что не вся деятельность
записи будут перекрываться.
Я не слишком уверен, как подойти к этому. Я посмотрел на некоторые примеры CTE, но ничего, что, кажется, не соответствует тому, что я пытаюсь сделать (возможно, слишком амбициозно .. особенно сценарий записи 3 и 5?)
Любая помощь / примеры будут высоко оценены.