Добрый вечер, коллеги

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


Формально в поле TFDATETIME хранится время в таком формате '2019.04.26 10:01', и данные в нем соответствуют PAIRDATETIME. Источник данных дает дату в виде строки, которая записывается в исходном виде, и идет доп преобразование в формат TIMESTAMP в поле PAIRDATETIME.

Регистрируемых процессов может быть несколько (до 30) и иногда некоторые из них пропускают выдачу данных на каком-либо интервале. Ну вот пример реальных данных



Видно что процесс ID=1 не дал показания в 10:11, 10:12, 10:13, 10:14, процесс ID=2 не дал показания в 10:14 и 10:15.

Необходимо обработать исходные данные, добавив отсутствующие показатели, использовав ближайшие по времени ранее полученные данные. Т.е. для первого процесса необходимо добавить записи для времени 10:11, 10:12, 10:13, 10:14, использовав для заполнения данные за 10:10.

Время 10:14 не будет заполнено для обоих процессов, т.е. его нет в исходных измерениях.

Вот так должны выглядеть нормализованные/дополненные данные


Я написал процедуру получения недостающих данных вида

Процедура прекрасно работает, выбирая 1 индексированную запись.

Дальше я решил сделать перебор всех возможных вариантов следующим образом


Это как бы тоже работает, но перебор в циклах FOR SELECT идет натуралом и получается квадрат количества исходных строк - это количество неиндексированных чтений. Т.е., если всего записей 2 000, то чтений 4 000 000. Реально цикл измерений может дать и миллион записей - соответственно ждать окончания расчета можно будет до конца времен.

Куда рыть, собственно, как это сделать хотя бы до конца нашей эры?

ёёёёёolegsng,

пусть при добавлении сразу выполняется проверка.
Смотри перед добавлением на последнюю запись запись данного процесса. Если есть пропуски - добавляй не одну запись, а столько, сколько раз было пропущено. Можно даже табличку завести для хранения последней записи по каждому процессу.

Не, не взлетит. Я упустил еще одну важную деталь. Сырые данные пишутся в файлы, индивидуальные для каждого процесса, формально в формате сsv, потом анализатор последовательно читает файлы и их содержимое, разбирает на компоненты и скидывает в базу. Так что выяснить, какой будет distinct состав времен замеров можно выяснить только после добавления всех записей.

ёёёёёolegsngпропущено...


Не, не взлетит. Я упустил еще одну важную деталь. Сырые данные пишутся в файлы, индивидуальные для каждого процесса, формально в формате сsv, потом анализатор последовательно читает файлы и их содержимое, разбирает на компоненты и скидывает в базу. Так что выяснить, какой будет distinct состав времен замеров можно выяснить только после добавления всех записей.

Ну, при записи сырых данных в файл дописывай пропущенные.

Процессы записи сырых данных ничего не знают друг о друге и в каком периоде они получают/не получают данные. Допустим, первый процесс может видеть, что пропущен период 10:11-10:14, но он никак не может узнать, что время 10:11-10:13 появятся в другом процессе, а время 10:14 не появится никогда и добавлять запись для первого процесса со временем 10:14 не нужно.

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

ёёёёё,

да, тестирование процессов идет на одном глобальном интервале времени, допустим за год, период детализации - задается, допустим 1 минута, т.е. если в течении этой минуты в процессе произошли события изменения состояния процесса, то появляются данные для записи во внешний файл и они пишуться. Затем на том же глобальном интервале запускается второй .... N-й процессы, которые так же могут писать, а могут и не писать данные в свой внешний файл. Т.е. это не реал тайм, это последовательные прогоны процесса (фактически программы) на исторических данных с целью нахождения некоторых оптимальных параметров - фактически это имитация одновременной реальной работы программ (процессов) на одном временном интервале.

И потом необходимо заполнить пропуски данных по принципу, например для первого процесса - если есть период измерения в процессах, отличных от первого, которого нет в первом процессе - то добавить в первый процесс этот период, установить время этого процесса как у полученного времени из другого процесса и взяв остальные (значащие) данные из записи для первого процесса, ближайшей в прошедшем времени к времени добавляемой записи. Ух.

Короче, если временная дырка есть во всех процесах - ничего не делаем, а если данные появились только в одном процессе из, например, 20, то в 19 дописываем это фиктивное для них время и значащие данные получаем по алгоритму - создаем 19 дополнительных записей.