[РЕШЕНО] Повторяющиеся данные в БД и их запись.

[skysilver]

А зачем подстраиваться конкретно под хайчартс? Фреймворков для графиков тьма, и у всех свой набор возможностей, фич. Далеко не у всех есть тот же тип step. Изначально в МДМ вообще не было никакой поддержки хайчартс, были только pChart и jpGraph. А юзер вообще может захотеть юзать любой другой фреймворк использовать. Под всех не подстроишься.

Текущая логика хранения данный лично меня всем устраивает. Она логична, вполне понятна и применима более широко, нежели конкретно в связке с хайчартс. Более того исторические данные используются не только для построения графиков, графики - это лишь частный случай.

ksv, скажи, а как хайчартс на графике температуры нарисует горизонтальную линию, если убрать последнее повторяющееся значение?
Вот в 13-00 была темп-ра 24С. Датчик шлет каждые 10 минут одинаковые данные. А в 14-10 присылает 25С.
13-00 - 24
13-10 - 24
13-20 - 24
13-30 - 24
13-40 - 24
13-50 - 24
14-00 - 24
14-10 - 25
После оптимизации в базе останется
13-00 - 24
14-00 - 24
13-10 - 25
По этим данным с 13-00 до 14-00 будет горизонтальная линия, а с 14-00 до 14-10 аппроксимация роста температуры. Это правильный подход.
Если убрать 14-00 - 24, то аппроксимация уже будет не за 10 минут, как должно быть, а за весь рассматриваемый период - час и 10 минут. Это уже, имхо, полная хрень.

Спасибо всем за участие в дискуссии, извините, если кого оскорбил ненароком.

В споре рождается истина. Тут редко такие глобальные и интересные вопросы поднимаются. )) Можно и подискутировать.

[ksv]

Да, это я всё хорошо понимаю, тут вы правы абсолютно, с одной только оговоркой - это не "правильный подход", а "один из множества подходов".

Если кому интересно, вот мой подход.
В системе есть два типа источников данных - критичные и обычные (можно ещё ввести степень критичности, но это уже детали).

Для обычных источников данных я делаю длинный интервал опроса (к примеру, те же 10 мин), и не вписываю в БД повторяющихся данных. Для таких источников в БД будет (в рамках предложенного примера) всего две записи:
13-00 - 24
14-10 - 25
На графике будет прямая диагональная линия - апроксимация за 1ч. 10 мин, так как источник данных не критичный.

Для критичных источников данных я делаю короткий интервал опроса, также не вписываю повторяющихся данных, но ввожу дополнительный бинарный признак доступности текущих показаний датчика, хранящийся в БД отдельно (отдельное свойство объекта).
Для таких источников в БД также будет всего две записи:
13-00 - 24
14-10 - 25
С той лишь разницей, что интервал опроса чаще, к примеру - 1 мин. Бинарное свойство доступности данных хранит историю в БД с той же частотой - 1 мин, и также не содержит повторов. Грубо говоря, сохраняются только переходы 0-1 и 1-0. Таким образом, получив положительный признак доступности данных в 14-09 я узнаю, что температура в этот момент также была известна, не менялась и равна 24. Перед выводом на график я программно дополняю недостающее повторение данных перед изменением, и будет отрисована ступенька от 24 к 25 за одну минуту.

Может показаться слишком сложным, согласен. Никому не навязываю этот подход и не утверждаю, что он какой-то там правильный или неправильный, удобный или ещё какой-нибудь. Но факт тут один есть - минимизация объёма хранимых данных. Так как я хочу хранить историю за несколько лет, чтобы получить долгосрочную статистику для различной аналитики, то мне важен каждый лишний байт, который повлияет и на размер свободного пространства жёсткого диска, и на скорость работы запросов к БД. Одним словом - оптимизация.

Я понял уже, что в общем случае, для большей совместимости и большей простоты использования и для большинства незамороченных пользователей текущая реализация хранения данных mjd в БД наиболее оптимальна. Согласен с этим, точка. Просто для моих требований этот вариант не подходит, но его легко модифицировать под мои нужды, что я и сделаю.

[fandaymon]

Отреагировать проще всего (и правильнее) было бы таким ответом, который исходя из всего вышеизложенного напрашивается уже сам собой: "В mjd так сделано потому, что этот способ хранения данных обеспечивает правильную отрисовку именно этих поддерживаемых стилей графиков именно этой используемой в mjd библиотеки". Вот всё. Ответ понятен и удовлетворителен.

Да нет же - сделано так, потому что это правильный и простой способ хранения данных, без потери информации. Который позволяет без промежуточных вычислений нарисовать график. Позволяет без лишних вычислений найти в базе момент, когда данные начали изменяться.
Альтернатив по сути-то и нету.

Что кажется правильным вам - хранить только точку начала отрезка.
Плюс - небольшая экономия на объеме данных
Минусы:
1. добавление нового поля объекту (период измерения)
2. для правильной отрисовки графика всё равно вторую точку надо вычислять
3. не работает в случае датчиков, выдающих непериодичные данные. Не зная периода мы не можем посчитать в какой момент величина начала менятся

т.е. плюс на мой взгляд ну никак не перевешивает минусы.

По поводу 2 пункта подробнее - наш условный термометра каждые 5 минут в течение часа показывал нам 0 градусов, в 60 минут показал 10 градусов. Правильный график - отрезок (0,0)-(55.0), потом отрезок (55,0)- (60,10)
Если отбросить точку (55,0) то в зависимости от настройки нам нарисуют либо (0,0)-(60,10), либо (0,0)-(60,0) + (60,0)-(60,10), либо (0,0)-(0,10) + (0,10)-(60,10). Все три графика это совсем не то, что нам нужно

[xor]

Эээ, по-моему уже где-то писал, у меня в подвале/погребе изменение температуры на полградуса раз в несколько дней. Я храню повторы. История температуры в помещениях - год. И не климатические данные занимают львиную долю объема. Но у меня жёсткий диск

Отправлено с моего Redmi 4X через Tapatalk

[skysilver]

Может показаться слишком сложным, согласен.

Вот заморочился дак заморочился. Из всех юзеров МДМ такое, наверно, может пригодиться только 1%, если не меньше.

[xor]

Тут ещё как будут работать "исторические" функции МЖД, особенно, среднее, оно предполагает равномерное во времени распределение данных в таблице, по-моему. Не видел, вроде, в коде нормализации по времени.

Отправлено с моего Redmi 4X через Tapatalk

[ksv]

Эээ, по-моему уже где-то писал, у меня в подвале/погребе изменение температуры на полградуса раз в несколько дней. Я храню повторы. История температуры в помещениях - год. И не климатические данные занимают львиную долю объема. Но у меня жёсткий диск

Вот отличный пример одного из множеств подходов. Для каждой задачи оптимальный алгоритм свой. Просто дефолтный алгоритм хранения в mjd в общем случае в той или иной мере удовлетворяет всем задачам и подходит для большинства. И при этом не является и не может являться оптимальным для всего множества задач. Для такого подвального датчика я бы, наверное, тоже хранил все значения, но с большим интервалом (скажем, раз в 12 часов). А климатические данные мы тут рассматриваем для примера только.

Может показаться слишком сложным, согласен.

Вот заморочился дак заморочился. Из всех юзеров МДМ такое, наверно, может пригодиться только 1%, если не меньше.

Заморачиваться и разбираться в деталях - это моё свойство, уж не знаю, к сожалению или к счастью. Хотел понять зачем так сделано, понял зачем, не устроило, сделаю иначе.

Тут ещё как будут работать "исторические" функции МЖД, особенно, среднее, оно предполагает равномерное во времени распределение данных в таблице, по-моему. Не видел, вроде, в коде нормализации по времени.

Вот про это я пока что ещё не в курсе. И не исключаю, что пересмотрю своё мнение под влиянием вновь откроющихся обстоятельств.

[Chainik]

Про функции работы с историей (чтобы долго не искать).
https://majordomo.smartliving.ru/forum/ ... f=7&t=2997

[ksv]

Про функции работы с историей (чтобы долго не искать).
https://majordomo.smartliving.ru/forum/ ... f=7&t=2997

Вот спасибо! Я под это дело нашёл полную страничку со встроенными функциями https://kb.smartliving.ru/vstroennie-v- ... o-funkcii/
На главной странице базы знаний ссылки на неё что-то не увидел.

[xor]

Опа! При отсутствии нормально распределенных данных по времени (без дубликатов) штатная историческая функция среднего getHistoryAvg будет работать не верно, она берет значения за период, складывает их и делит на их количество.
При отсутствии дубликатов это будет выдавать чушь - 10 часов температура 0 градусов, 1 час 20 градусов (0+20)/2, ну или /3, если начало-конец пушутся.