Здравствуйте, dronlinux, Вы писали:
Р>>Ты знаешь, какое поле апдейтится последним?
D>Да знаю. А я понял вашу мысль.
Сугубо ИМХО, но такая завязка опасна. Таблица в БД может измениться, порядок обхода колонок — тоже и тогда кто-то будет ломать голову на предмет косяков в истории. К тому же апдейтить одновременно может не один пользователь, а несколько. Какие-то изменения потеряются. В этой каше потом не разберётесь. Лучше дотошно записывайте каждое изменение, а потом обрабатывайте этот fine-grained список любым из удобных способов.
create table log (
id int(11) auto_increment,
field_name varchar(255) not null,
field_value blob,
record_id int (11) not null,
date_create timestamp
);
Соответственно в триггере писать что-то в духе
if (old.field_name != new.field_name)
insert into log (field_name, field_value, record_id, date_create)
values ('field_name', new.field_value, new.id, NOW())
В истории будет хранится не вся запись, а только измененные поля.
Потом можно будет делать необходимые выборки (допустим, что было в базе 12 мая 2007 года в 17:45).
Здравствуйте, Бабошин Андрей, Вы писали:
БА>В истории будет хранится не вся запись, а только измененные поля. БА>Потом можно будет делать необходимые выборки (допустим, что было в базе 12 мая 2007 года в 17:45).
Кстати, я именно это и имел в виду, только принял за само собой разумеящееся. Нет смысла плодить дубликаты.
Здравствуйте, dronlinux, Вы писали:
Р>>Ты знаешь, какое поле апдейтится последним? D>Да знаю. А я понял вашу мысль. То есть как только оно изменится тогда брать всю запись и в историю? Но условие обновления этого поля таковы, что оно может изменится а может и нет.
Если апдейт выполняется хранимой процедурой X, может быть ты её переименуешь в X_OLD и поверх неё сделаешь враппер X, вызывающий X_OLD, после чего пишущий историю?
Правда, если таблица модифицируется не только этой процедурой, триггеры всё равно будут нужны, и придётся их дизаблить в X на время выполнения X_OLD (если такое вообще возможно — либо через DDL, либо через какие-нибудь in-memory переменные).
Здравствуйте, Бабошин Андрей, Вы писали:
БА>В истории будет хранится не вся запись, а только измененные поля. БА>Потом можно будет делать необходимые выборки (допустим, что было в базе 12 мая 2007 года в 17:45).
Такая схема максимум годится чтобы на страницу вытащить состояние одной записи.
Тот, кому придется писать отчет по состоянию таблицы на какую либо дату проклянет того, кто придумал схему хранения "одна строка-одно поле", потому что каждое поле тут придется обрабатывать отдельным джойном/селектом.
А если в отчете требуется не только состояние, а ещё и какая-нибудь бизнес логика, то вообще тушите свет.
Здравствуйте, avpavlov, Вы писали:
A>Такая схема максимум годится чтобы на страницу вытащить состояние одной записи.
A>Тот, кому придется писать отчет по состоянию таблицы на какую либо дату проклянет того, кто придумал схему хранения "одна строка-одно поле", потому что каждое поле тут придется обрабатывать отдельным джойном/селектом.
A>А если в отчете требуется не только состояние, а ещё и какая-нибудь бизнес логика, то вообще тушите свет.
А кто мешает обрабатывать эти (на ваш взгляд слишком низкоуровневые) данные? Хоть вьюшкой, хоть сторенными процедурами. Самое главное — не потерять информацию об изменених, а оптимизацию по <подставить необходимое> всегда можно будет сделать.
D>А кто мешает обрабатывать эти (на ваш взгляд слишком низкоуровневые) данные? Хоть вьюшкой, хоть сторенными процедурами. Самое главное — не потерять информацию об изменених, а оптимизацию по <подставить необходимое> всегда можно будет сделать.
Никто не мешает. Но проклянут всё равно. Потому что если данные собираются с целью генерации различных отчетов по состоянию на определенную дату, то решать надо именно эту задачу, и при выборе схемы хранения версионных данных отталкиваться от этой задачи, а не придумывать универсальный алгоритм хранения версионных данных.
Здравствуйте, avpavlov, Вы писали:
A>Никто не мешает. Но проклянут всё равно. Потому что если данные собираются с целью генерации различных отчетов по состоянию на определенную дату, то решать надо именно эту задачу, и при выборе схемы хранения версионных данных отталкиваться от этой задачи, а не придумывать универсальный алгоритм хранения версионных данных.
Если важен полный снэпшот и нет желания собирать его вручную из отдельных изменений, то действительно можно делать снимок всей записи при изменении одного поля, начхав на избыточность и требуемое место. Загвоздка не в этом, а в попытках искусственно объединить несколько отдельных (с точки зрения БД) событий по расплывчатому критерию.
Здравствуйте, Delight, Вы писали:
D>Здравствуйте, avpavlov, Вы писали:
D>Если важен полный снэпшот и нет желания собирать его вручную из отдельных изменений, то действительно можно делать снимок всей записи при изменении одного поля, начхав на избыточность и требуемое место. Загвоздка не в этом, а в попытках искусственно объединить несколько отдельных (с точки зрения БД) событий по расплывчатому критерию.
Исходя из исходного вопроса, мне показалось надо будет показывать изменения между двумя опеределенными датами, соответственно хранить можно утреннее/вечернее состояние записи — этого скорее всего будет достаточно.
D> начхав на избыточность и требуемое место
Если обновится хотя бы половина из 40 полей, то сохранение записи целиком один раз будет куда выгоднее чем 20 мини-записей, потому что в каждой будет продублировано время и ИД записи .
Здравствуйте, avpavlov, Вы писали:
D>>Здравствуйте, avpavlov, Вы писали:
A>Исходя из исходного вопроса, мне показалось надо будет показывать изменения между двумя опеределенными датами, соответственно хранить можно утреннее/вечернее состояние записи — этого скорее всего будет достаточно.
А как же внутридневные изменения?
A>Если обновится хотя бы половина из 40 полей, то сохранение записи целиком один раз будет куда выгоднее чем 20 мини-записей, потому что в каждой будет продублировано время и ИД записи .
Выгоднее. Но отловить момент, когда надо сохранить эту запись весьма непросто.
К тому же апдейтить одновременно может не один пользователь, а несколько. Какие-то изменения потеряются. В этой каше потом не разберётесь. Лучше дотошно записывайте каждое изменение, а потом обрабатывайте этот fine-grained список любым из удобных способов.
