Сбор статистики во времени

[alexcon314]

Здравствуйте.
Имеется таблица БД MySql. Данные в ней добавляются, обновляются, удаляются произвольно в течение рабочего дня, хотя наиболее задействован на некотором периоде времени (месяц) определенный диапазон записей (строк), добавленные за этот переиод, т.е. "свежие". Впрочем, это, наверно, не суть.
Вопрос: как выявить динамику изменения значений, хранящихся в этой таблице, во времени.
Как подойти к решению этого вопроса?
Единственное, что мне пока удалось придумать - делать с заданным периодом снапшоты с этой таблицы. Но это довольно накладно, поскольку проект, где эта таблица используется, не одногодичный, и к тому же часть данных при этом теряется.
Цель - прогнозировать на основе статистической обработки данных в этой таблице за разные периоды времени дальнейший ход процесса и т.п.
Склоняюсь к мысли, что прежде требуется проработать детально правила сбора информации и под них что-то придумывать. Но ... это не совсем то, что надо. Или даже совсем не то. Правила могут измениться.
Если есть хорошие ссылки на теорию - буду признателен.
Задача, возможно, схожа, например, с отображением статистики посещаемости страниц сайта. Как это реализуется?

[Skubent]

Ммм... Не совсем понял, надо количество записей в таблице в контрольных точках времени снимать или по записям в таблице одно(два-три...) значение отслеживать ?

[alexcon314]

Skubent, спасибо за отклик. Постараюсь уточнить.
Есть приложение, работающее с таблицей в базе, из него пользователь вносит изменения.
Мне необходимо вести "лог" всех изменений в таблице с привязкой ко времени в течение длительного периода. Записывать все в файл(ы) в виде форматированного текста можно, но придется писать свое приложение-анализатор, чтобы приводить записи к удобной для обработки форме.
С другой стороны, анализатор будет делать операции, типичные для сервера БД: сортировка, выборка по условию и т.п., работая с массивом данных в логе. Вот я и подумал: нельзя ли это все организовать средствами самого сервера MySql?
В простейшем примере: нужно знать, каково было значение конкретного поля когда угодно с момента его появления в таблице.

[Skubent]

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

INSERT INTO `log` SET `data_id` = ${что_мы_там_меняем},`old_data` = $old_data, `new_data` = $new_data, `update_time` = mktime(), `status` = 0;
Потом делать апдейт рабочей таблицы от пользователя, потом апдейтить запись в логе на status = 1.

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

[alexcon314]

Спасибо, Skubent. Механизм ясен. За работу.
Только еще один вопрос: как в этой эмуляции транзакции можно реализовать откат при ошибке?

[Skubent]

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

ЗЫ. глянул на историю версий мускула. Транзакции там есть уже лет пять, это чтоб огород не городить.

[alexcon314]

Еще раз спасибо. С уважением.