Как бы вы поддерживали историю в таблицах SQL? - PullRequest
2 голосов
/ 18 февраля 2009

Я проектирую базу данных для хранения информации о продукте и хочу хранить несколько месяцев исторических (ценовых) данных для дальнейшего использования. Тем не менее, я хотел бы, после определенного периода, начать перезаписывать начальные записи с минимальными усилиями, чтобы найти начальные записи. У кого-нибудь есть хорошее представление о том, как подойти к этой проблеме? Мой первоначальный дизайн - иметь таблицу с именем исторические данные, и каждый день она извлекает активные данные и сохраняет их в исторической базе данных с отметкой времени. У кого-нибудь есть идея получше? Или видно что у меня не так?

Ответы [ 5 ]

2 голосов
/ 18 февраля 2009

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

Возможно иметь лучшее решение, но оно должно быть управляемым событиями. Если у вас есть сервер базы данных, который поддерживает события или триггеры (например, MS SQL), вы должны написать код триггера, который создает запись в таблице истории. Если ваш сервер не поддерживает триггеры, вы можете добавить в приложение код архивации (во время операции сохранения).

1 голос
/ 18 февраля 2009

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

1 голос
/ 18 февраля 2009

Это гораздо более широкая тема, чем кажется на первый взгляд. У Мартина Фаулера есть хороший рассказ о "вещах, которые меняются со временем".

0 голосов
/ 18 февраля 2009

Я бы хотел, после определенного периода, начать перезаписывать начальные записи с минимальными усилиями, чтобы найти начальные записи

Мы храним данные в архивных таблицах, используя триггер, как предлагали другие. Наша архивная таблица имеет дополнительный столбец для AuditDate и хранит «удаленные» данные - то есть предыдущую версию данных. Текущие данные хранятся только в фактической таблице.

Мы удаляем таблицу Archive с бизнес-правилом в духе «Удалить все архивные данные старше 3 месяцев, если существует хотя бы одна архивная запись младше 3 месяцев; удалить все архивные данные старше 6 месяцев»

Таким образом, если за последние 3 месяца цены не изменились, у вас все равно будет запись об изменении цены за период 3-6 месяцев назад.

(Спросите, нужен ли вам пример самореферентного соединения для удаления или триггер для сохранения изменений в таблице Archive)

0 голосов
/ 18 февраля 2009

IMO ваш подход кажется разумным, если требуемые данные истории являются моментальным снимком данных на конец дня - в прошлом я использовал аналогичный подход с ночными заданиями (SP), которые собирают новые данные дня, ставят метку времени и затем используйте «удалить все данные с временной отметкой <сегодня - x», где x - это период времени данных, которые я хочу сохранить. </p>

Если вам нужно отследить все изменения в истории, вам нужно посмотреть на триггеры.

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