Добрый день.
Не могу решить, на первый взгляд, не сложную задачу. Нужно соединить 3 таблицы, в которых есть поле ID, begda и endda, плюс дополнительные поля.
Если кто знаком с HR, то это HRP1005, T710 и z-таблица. В которых ID - это код штатной должности, ну и begda и endda. В таблице z есть поле, которое можно заполнять руками.
В каждой таблице на одну ID могут быть несколько неперекрывающихся записей, но периоды в отношении 3х таблиц могут перекрываться.
Т.е. в 1ой таблице может быть запись, на один период которой, может быть 2 записи второй таблицы, а в третей 3 периода будут входить в один период первой, и к примеру 10 дней 4го периода, endda у которого, больше endda периода первой таблицы. Самому тяжело понять, что написал, но как-то так.
Нужно проверять на появление новых должностей в HRP1005, повышение окладов в T710, и в Z могут появляться новые записи.
И я никак не могу сложить эту мозайку.
Я пошел по варианту анализа каждой записи HRP1005, далее в Z таблице, и потом каждой записи в t710. Но зашел в тупик.
Есть вариант сложить во внутреннюю таблицу все периоды из 3х таблиц, разбить их на все минимальные периоды и дальше тянуть по периодам, информацию из 3х таблиц. Но слабо пока представляю как это сделать.
Чувствую 5ой точкой, что есть проще вариант, но не могу его найти. И думаю не в том направлении.
Может кто подтолкнет к правильному решению?
Заранее спасибо.

P.S. Можно ли сделать это ракурсом 3х таблиц?

Фокус в том, что можно проверять записи во всех таблицах только на одну дату.
В разрезе каких дат нужно строить отчет?

В разрезе дат, точней периодов всех таблиц, и во внутренюю таблицу складывать все "кусочки" и по этим кусочкам тянуть инфу из всех трех таблиц.
В итоге 3я таблица будет равна внутренней.

Путем рисования в тетрадке пришел к выводу, что во внутренней таблице будут наиболее мелкие периоды их всех 3х таблиц.
1 |-------------|--------------|-------------| (hrp1005)
2 |------|-------------|-------|-------------| (t710)
3 |----------|--|------|-------|-------------| (z)

4 |------|---|--|------|-------|-------------| внутренняя таблица

Как-то так.
И теперь для каждого кусочка внутренней таблицы нужно тянуть тип, группу, область их hrp1005.
Минимальный и максимальный оклад по типу-группе-области из Т710.
Установленный по штатке оклад из z.

как вариант - считать по дням, тогда не нужно заморачиваться с нарезками периодов,
предварительно выбрать из бд данные с мин даты по макс возможную дату, раздельно без join,
по выбранным данным составить таблицы (или одну сводную) у которых ключом будет дата,
работать будет дольше, но если есть данные по дням, то можно собрать любой отчёт

К сожалению не вариант. И так в фоне полчаса отрабатывает.

Если решите делать через внутренние таблицы, то есть замечательный ФМ RH_CUT_PERIODS, который разобьет начальные данные на нужные периоды.

Ухты, походу то, что надо. Спасибо.
А то я сам велосипед начал придумывать.

Добрый день!
Ракурсом 3 таблиц это не сделать.
Я решал подобную задачу (не такая уж она и простая)

Теоретически можно сделать через периоды, но это получится довольно сложный алгоритм (при N таблицах сложность растет геометрически)
Ключевая подсказка в этом направлении -
Условие пересечения двух периодов:
( T1.begda <= T2.endda ) AND
( T2.begda <= T1.endda )
выводится по закону де моргана, отрицанием условия непересечения:
(T1.begda > T2.endda ) OR
(T2.begda > T1.endda ).
можете построить на графиках.
Это теория.

Практичный вариант не приводящий к усложненному алгоритму:
Составить таблицу по дням (зафиксировать состояние параметров на каждый день).
После ее заполнения преобразовать обратно в таблицу периодов.


P.S. Для работы с периодами можно еще использовать логическую базу данных и оператор
PROVIDE f1 f2 ... FROM itab1 g1 g2 ... FROM itab2
...
FROM itabn
...
BETWEEN f AND g.
ENDPROVIDE.
в хелпе описано как работать, но еще раз предупреждаю работа с периодами это тупиковый (приводящий к разрастанию сложности) путь. И вообще ldb и provide это устаревшие эелементы языка (использовались еще до появления SQL)

Я немного не пойму про таблицу по дням. Как это должно выглядеть?

Ну пока я не понял с днями, на первом месте вариант использовать фм для обрезки дат, предварительно во внутреннюю таблицу кинуть все периоды из 3х таблиц, а потом уже всю инфу тянуть по этим периодам из трех таблиц.

1) выборка из таблиц бд за заданный период в раздельные внутр таблицы
2) цикл с миним даты периода по максимальную:
для даты Di чтение из каждой внутр таблицы по условию begda <= Di <= endda,
прочитанные строки вносим как запись за дату Di в соотв дневные таблицы
(т.е. замена begda-endda на date)

да, именно так

Я этот ФМ не использовал, тоже не очень пока понял ее интерфейс, внутри посмотрел - там не особо сложно
мне кажется что он как раз что то подобное алгоритму "по дням" и выполняет
В общем с чем будет проще разобраться то и используй

Совет по оптимизации:
Алгоритм абсолютно верен, но выделенное место будет тормозить (даже сортированная таблица не поможет)
Поэтому можно так соптимизировать:
1) выборка из таблиц бд за заданный период в раздельные внутр таблицы
2) каждую запись в таблице преобразуем в набор записей (на каждый Di) от begda до endda.
так должно работать быстро

мысль понятна, однако, сомнительно что во внутр табл будет много периодов(записей),

ещё как вариант:
можно сортировать напр по begda (в endda как обычно м.б. 99991231),
затем использовать read .. binary search:

-либо-
удалять строки периодов из внутр таблиц по завершению обхода периода

Помнится в некоторых инфотипах, вроде "дни отсутствия", записи были такие:
begda endda
19.01.2013 19.01.2013
24.01.2013 24.01.2013
25.01.2013 25.01.2013
и т д
Во всяком случае - "в фоне полчаса отрабатывает" я не могу по другому объяснить


Выглядит несколько заумно, но идея отсортировать и просто брать по begda хорошая, периоды как правило не пересекаются
но < и > с binary search и sorted table не работают к сожалению.

Я бы примерно так сделал:

и дальше работать ужу с days1 - с подневной работать намного проще
а в году всего 365 дней - это копейки
остальные 2 таблицы - аналогично


Лучше не удалять записи из исходной таблицы, особенно когда по ней идешь в LOOPе, работает конечно, но некрасиво, все равно что сам себя за волосы поднимаешь