Источники событий и ретроактивные события

Мне нужно включить ретроактивные события в мой поток событий, и я не уверен, как лучше всего это реализовать.

Нам нужно сохранить исходный поток событий без изменений для аудита и всех других стандартных преимуществ. Поток событий также носит временной характер, что дает нам возможность видеть значения для любой точки истории. т. е. значение x было 10.00 в 17:00 1 июня. Время от времени мы узнаем 5 июня, что значение x действительно было 12:00 в 17:00 1 июня. В этом сценарии мы ссылаемся на 10,00 как на текущее значение и на 12,00 как на фактическое значение, и мы отслеживаем оба эти значения в потоке событий.

Восстановление состояния текущего значения — это прямой запрос из самого последнего снимка до 17:00 1 июня и всех событий до 1 июня.

В чем я сомневаюсь, так это в восстановлении существующего состояния. Если в модели есть корректировка по факту, то она должна использоваться по умолчанию, а не по состоянию на момент, но я не вижу никакого способа определить, есть ли по состоянию на момент исправление без чтения всего потока событий с момента времени до настоящего времени (это может быть большим), и большинство изменений не будут иметь значения, поскольку они будут связаны с будущими изменениями, а не с рассматриваемым моментом времени.

Есть ли другой подход, на который я должен смотреть здесь?

Спасибо, Крис


person CCondron    schedule 09.04.2012    source источник


Ответы (1)


Я думаю, что вы имеете в виду битемпоральную модель данных. То есть можно ответить не только «кто победил на президентских выборах в США в 2000 году», но и «кто, по нашему мнению, победил на президентских выборах в США вечером в день выборов в 2000 году».

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

Лучший способ запроса этих данных зависит от того, на какие вопросы вы хотите ответить. Существует несколько хороших статей о том, как создавать темпоральные и битемпоральные схемы баз данных, которые будут заполняться проекторы, использующие поток ваших событий.

person Sebastian Good    schedule 15.05.2012
comment
Да, двухвременная модель данных — это суть вопроса; Я стараюсь избегать создания двухвременной модели SQL. (Я делал это раньше.) В настоящее время я рассматриваю создание проекции SQL для состояния «как есть», поскольку это будет преобладающий запрос, и я читаю «как есть» напрямую из потока событий. Другой проблемой, которая у меня была, было частичное или полное изменение формата ретроактивных событий. Основываясь на уроке Грега Янга на прошлой неделе, я буду использовать полную инверсию для ясности в потоке событий. (Это также упростит обновление текущего прогноза.) Спасибо, Крис. - person CCondron; 30.05.2012
comment
Если банк ошибочно добавил на ваш счет 20 долларов вместо 15, есть два способа отменить транзакцию. 1) Частичным разворотом будет запись коррекции на -5$. 2) Полный разворот будет означать запись разворота на -20$ и исправленную транзакцию на 15$. Большинство банковских/финансовых систем используют исключительно полное сторнирование для сохранения журнала аудита. (При частичном сторнировании правильная транзакция всегда подразумевается, тогда как полное сторнирование включает правильную транзакцию.) - person CCondron; 31.05.2012
comment
В этом есть смысл. Итак, вы будете строить простую модель чтения из потока событий в реальном времени, а затем запрашивать поток событий из хорошо известных моментальных снимков, чтобы выполнять запросы «как есть»? - person Sebastian Good; 01.06.2012
comment
Тем не менее, событие полного разворота + событие коррекции должно иметь двойную дату: Сегодня я говорю, что в прошлом году я должен был сделать xxx. - person Xavi Montero; 26.09.2018