Как вставить значение за "вчера"?

[ErmolenkoM]

Решаю задачу - есть ежедневные данные, то есть величина на каждый день. Но поступают эти данные не регулярно - с пропусками по дням, при этом данные за пропущенные дни приходят, но позже. Хочу строить графики. Подскажите как уложить данные за вчерашний/позавчерашний день, что бы на графике все было красиво.
Я как бы понимаю, что можно простой INSERT в phistory, но может есть вариант покрасивее?

[Palko]

складывать в массив, а потом UPDATE на нужную глубину в phistory?

[sergejey]

Что-то ничего в голову не приходит, кроме как приведённый вариант со вставкой в phistory "задним числом"

[LutsenkoDenis]

Как мне кажется пихать задним числом не лучший вариант.

Сейчас таблица phistory выглядит так:

Код: Выделить всё

CREATE TABLE IF NOT EXISTS `phistory` (
  `ID` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `VALUE_ID` int(10) unsigned NOT NULL DEFAULT '0',
  `ADDED` datetime DEFAULT NULL,
  `VALUE` varchar(255) NOT NULL,
  PRIMARY KEY (`ID`),
  KEY `VALUE_ID` (`VALUE_ID`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 AUTO_INCREMENT=1

Собственно при записи данных в phistory, в поле ADDED добавляется дата записи в таблицу или дата, которую передали.

На мой взгляд в phistory должно быть не одно поле с датой, а два или даже три поля.
Например:

• LM_DATE - дата, когда что-то изменилось в таблице. (Изменяется всегда при каждой операции с таблицей)
  REG_DATE - дата, когда была вставка данных в таблицу (Дата, когда данные пришли и произошла вставка в таблицу)
  OPER_DATE - дата, которую получили с датчика или еще как. Собственно та дата которая нас интересует.(реальная дата которую передавал счётчик или ещё какое-либо устройство)

Собственно что это даст:
1. По полю LM_DATE, мы можем узнать когда были какие-либо изменения с данными после их первой вставки в таблицу.
2. Поле REG_DATE хранит дату когда была добавлена запись в таблицу.
3. Поле OPER_DATE содержит дату операции, ну там например дата снятия показания со счётчика. По данному полю, как наз можно строить график, так как уже не важно когда пришли данные, сегодня или через месяц.

[ErmolenkoM]

Что-то мне кажется не очень хорошая идея с дополнительными полями. Таблица и так одна из самых нагруженных, а добавлять в неё избыточные (в 99% случаев) поля... Ну как-то мне не очень.

[LutsenkoDenis]

А иметь одно поле с датой, которое можно интерпретировать по разному это хорошая идея?

От того что в таблице будет еще несколько полей, она не станет более нагруженной.

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

Но я не претендую на истину в последней инстанции.

[ksgroup]

Нагруженная таблица из за того что в данную таблицу пишется практически всё что только можно записать.

Присоединяюсь! Таблица перегружена. Может имеет смысл сделать подобную таблицу для каждого класса объектов? Что бы при создании класса создавалась сразу же и его таблица истории. Все объекты одного класса чтоб сохраняли данные в его таблицу. Не будет сотен обращений к одной и той же таблице, таблицы истории станут меньше в размерах, что ускорит поиск в них. Кстати и потеря данных думаю будет менее вероятна. Сейчас если погибнет phistory - погибнет вся накопленная от датчиков информация. Понимаю что резервное копирование наше все, но не будешь же делать копии ежеминутно. Имея одну таблицу теряешь данные всех датчиков за время после резервного копирования, а если своя таблица для каждого класса то теряешь только данные датчиков одного только класса.