Xpoint
   [напомнить пароль]

История изменений

Метки: [без меток]
2006-05-17 01:33:11 [обр] kuglik[досье]

Требуется вести историю изменений характеристик какого-либо подучётного объекта. Вот мною изобретённый "велосипед".

Методы:

  1. Вести историю по дате изменения. Интуитивно понятный и потому чаще всего встречаемый.

+ простота и прозрачность
- выборка списка объектов с сортировкой по историческому признаку.
Например, для вывода списка документов с названиями клиентов, которые меняются во времени, необходимо для каждого из них выбрать актуальное название клиента соответствующее дате документа. А это уже не просто JOIN, а с условием на сравнение дат: последняя, но не позже чем. Кроме того, не все ссылающиеся объекты могут иметь дату относительно которой и определяется актуальность.

  1. По версии.

+ прозрачность. Простота создания списков.
- необходимлсть хранить в ссылающихся на объект документах дополнительное поле версии.

  1. По дополнительному номеру.

+ Работа с историческими данными не отличается от работы с не историческими
- некоторая путаница с двумя идентификаторами.

Помогите, пожалуйста, выбрать методику. Укажите не найденные мной плюсы и минусы. Может есть ещё какие-то другие принципы посторения истории.

Следующий вопрос неразрывно связан с первым. Как лучше организовать хранение истории дополнительных свойств? Точно также как и основного объекта? Или изменения свойств фиксировать как изменения самого объекта? Должен ли основной объект при изменении своего состояния копировать все дополнительные св-ва?

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

спустя 27 дней [обр] Филипп Ткачев(0/112)[досье]

У меня возникла следующая идея по вашему вопросу:
Создавать набор таблиц, каждая из которых будет отражать модифицируемую характеристику объекта.
Структура такая:

  • номер изменения (поле с автоинкрементом)
  • идентификатор объекта
  • значение старой характеристики
  • время изменения

В нее вносить предыдущее значение характеристики объекта.
То есть тут получается именно историческая характеристика.
Хотя если добавить еще поле версии, получится и версионная система.
Но, как мне кажется, это обычно и бывает нужно.

Powered by POEM™ Engine Copyright © 2002-2005