Статья:
Протоколирование действий пользователей и версионность записей

Автор(ы): Смирнов Андрей
Дата: 23.10.2004
Рассматриваются подходы к отслеживанию действий пользователей в БД, протоколирование изменений и получение данных по состоянию на какой-либо момент.

Авторы:
Смирнов Андрей

Аннотация:
Рассматриваются подходы к отслеживанию действий пользователей в БД, протоколирование изменений и получение данных по состоянию на какой-либо момент.

А вот расскажите мне, зачем выкладывать в форум аннотации статей из RSDN Magazine. Ну прочитал я аннотацию. А дальше что? Прочитать статью я все равно не могу. С тем же успехом можно прочитать эту аннотацию и в разделе RSDN Magazine

Здравствуйте, robot, Вы писали:

R>А вот расскажите мне, зачем выкладывать в форум аннотации статей из RSDN Magazine. Ну прочитал я аннотацию. А дальше что? Прочитать статью я все равно не могу. С тем же успехом можно прочитать эту аннотацию и в разделе RSDN Magazine

Для того, чтобы под этой рецензией прочитавшие могли высказать свое мнение и задать вопросы автору. IMHO

Здравствуйте, Смирнов Андрей, Вы писали:

А почему не рассматривается следующий способ хранения исторических данных: в каждую таблицу добавляется 2 поля:
1) дата, с которой имеет действие данная строка
2) дата, по которую действует данная строка.

У нас такой способ применяется для справочников.
Например справочник курса валют:

01/01/04 — 03/01/04 29.9
04/01/04 — 10/01/04 31.2

Что думаешь про такой способ хранения истории записей ?

Если говорить о курсах валют, то такие темы в статье не рассматривается. В статье рассмотрены "версионность записей". Вот если бы нужно было посмотреть состояние курса валюты на 01/01/04, каким он был скажем 03/01/04, то тогда можно было бы применять описанные в статье подходы. Курс валют — это не из области версий записей, это из области time-series. На эту тему есть хорошая книга, где все вопросы по time series хорошо описаны, вот только не очень хорошо помню автора — Snordan или что-то вроде этого.

Здравствуйте, andsm, Вы писали:

A>Если говорить о курсах валют, то такие темы в статье не рассматривается. В статье рассмотрены "версионность записей". Вот если бы нужно было посмотреть состояние курса валюты на 01/01/04, каким он был скажем 03/01/04, то тогда можно было бы применять описанные в статье подходы. Курс валют — это не из области версий записей, это из области time-series. На эту тему есть хорошая книга, где все вопросы по time series хорошо описаны, вот только не очень хорошо помню автора — Snordan или что-то вроде этого.

Можно скачать с сайта автора: Developing Time-Oriented Database Applications in SQL by Richard T. Snodgrass — 5MB

Здравствуйте, DemAS, Вы писали:

DAS> 01/01/04 — 03/01/04 29.9
DAS> 04/01/04 — 10/01/04 31.2
DAS> Что думаешь про такой способ хранения истории записей ?

Смысл второго поля?

Здравствуйте, Real 3L0, Вы писали:

DAS>> 04/01/04 — 10/01/04 31.2
DAS>> Что думаешь про такой способ хранения истории записей ?

R3>Смысл второго поля?

Имеет смысл при удалении записи.
Т.е. не изменение значения, а его отсутствие в течении промежутка времени.

Здравствуйте, seregaa, Вы писали:

DAS>>> Что думаешь про такой способ хранения истории записей ?

R3>>Смысл второго поля?

S>Имеет смысл при удалении записи.
S>Т.е. не изменение значения, а его отсутствие в течении промежутка времени.

Давай на примере. В чем различие удаления здесь
01/01/04 — 03/01/04 29.9
04/01/04 — 10/01/04 31.2
и здесь
01/01/04 29.9
04/01/04 31.2
первой строки?

Здравствуйте, Real 3L0, Вы писали:

R3>Давай на примере. В чем различие удаления здесь
R3>01/01/04 — 03/01/04 29.9
R3>04/01/04 — 10/01/04 31.2
R3>и здесь
R3>01/01/04 29.9
R3>04/01/04 31.2
R3>первой строки?

Смысл в том, что если на 04/01/04 нет сведений, то будем иметь такую запись:
01/01/04 — 03/01/04 29.9
05/01/04 — 10/01/04 31.4

Здравствуйте, DemAS, Вы писали:

DAS> Что думаешь про такой способ хранения истории записей ?

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

Здравствуйте, seregaa, Вы писали:

S>Смысл в том, что если на 04/01/04 нет сведений, то будем иметь такую запись:
S>01/01/04 — 03/01/04 29.9
S>05/01/04 — 10/01/04 31.4

А можно и такую
03/01/04 29.9
04/01/04 null
10/01/04 31.4

Здравствуйте, DemAS, Вы писали:

DAS> У нас такой способ применяется для справочников.
DAS> Например справочник курса валют:
DAS> 01/01/04 — 03/01/04 29.9
DAS> 04/01/04 — 10/01/04 31.2

Если вам так важна функция вычисление окон (назаполненых дат) в справочнике валют, то почему не использовать списки?

-> id
|_ parent_id
   d_current
     rate

в этом случае вы соберете дыры в справочнике за один проход по таблице. select * from table where parent_id is null
вот этот момент не понятен?

зы: вообще функциональнее конечно будут двунаправленные списки, но тут они вообще ни к чему. вполне достаточно однонаправленных

День добрый. Хотел бы уточнить использование метода "таблиц-версий".

Предположим у нас есть несколько таблиц:
1. Договор
2. Банк
3. Контрагент
4. БанковскиеРеквизитыКонтрагента
И необходимо получать для договора (при его просмотре) те значения, который были на момент его создания (т.е. те версии записей).

В каждом договоре есть следующие ссылки:
1. Договор.Контрагент — Контрагент.КодВерсии
2. Договор.БанковскиеРеквизитыКонтрагента — БанковскиеРеквизитыКонтрагента.КодВерсии
Т.е. ссылки на версии. Вроде всё нормально, но есть следующая проблема:

БанковскиеРеквизитыКонтрагента ссылаются в свою очередь на Банк и Контрагента. Т.е. в каждой версии реквизитов есть ссылка на банк и контрагента. Вот тут-то и возникает вопрос: ссылка на банк и контрагента должна быть на кодверсии или на код?

По идее ссылка на банк должна быть на кодверсии, т.к. нам нужны данные именно той версии банка, когда была создана версия реквизитов. Но ссылаться на кодверсии (БанковскиеРеквизитыКонтрагента.Банк — Банк.КодВерсии) мы не можем. Почему? Вот почему: предположим, что данные банка меняются (т.е. создаётся новая версия). После этого мы пытаемся получить реквизиты данного банка, но сделать этого не сможем, т.к. в реквизитах ссылка (БанковскиеРеквизитыКонтрагента.Банк — Банк.КодВерсии) на старую версию банка, а на новую ни одна версия реквизитов не ссылается.

Для примера:
Банк
id instance_id
1 11
1 12
1 13

БанковскиеРеквизитыКонтрагента
id instance_id bank
1 21 11
1 22 11

Т.е. для 13-ой версии банка нет реквизитов (не обновлять же все таблицы в которых есть ссылка на версию банка при её редактировании).

Выходы их этой ситуации вижу следующие:
1. Хранить ссылку на версию банка в договоре.
2. Или использовать два поля для ссылки.

Что скажите?

Здравствуйте, Смирнов Андрей, Вы писали:

СА>Статья:
СА>Протоколирование действий пользователей и версионность записей

Автор(ы): Смирнов Андрей
Дата: 23.10.2004
Рассматриваются подходы к отслеживанию действий пользователей в БД, протоколирование изменений и получение данных по состоянию на какой-либо момент.

СА>Авторы:
СА> Смирнов Андрей

СА>Аннотация:
СА>Рассматриваются подходы к отслеживанию действий пользователей в БД, протоколирование изменений и получение данных по состоянию на какой-либо момент.

Могу поделиться своей системой протоколирования. Правда в ней есть ограничения на индексы — они должны быть в одном поле и типа Int, но его можно и расширить...
Ставится с одного скрипта. Управляется через триггеры.