Как лучше всего организовать хранение исторических данных?

Question

Я пытаюсь определить, как мне следует хранить исторические данные о транзакциях.

Должен ли я хранить его в одной таблице, где запись каждый раз просто вставляется заново с новой меткой времени?

Должен ли я вынести исторические данные в отдельную таблицу «истории» и хранить только текущие данные в «активной» таблице.

Если да, то как мне лучше всего это сделать?С триггером, который автоматически копирует данные в таблицу истории?Или с логикой в ​​моем приложении?

Обновление согласно комментарию Велбога:

Будут большие объемы исторических данных (сотни тысяч строк - в конечном итоге потенциально миллионы).

В первую очередь операции поиска и составления отчетов будут выполняться на исторических данных.

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

Answer 1

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

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

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

Answer 2

Этот вопрос идет по линии бизнес-логики.Сначала узнайте требования своего бизнеса, а затем начинайте оттуда.Хранилище данных — хорошее решение для такой ситуации.ETL предоставит вам множество вариантов работы с потоками данных.Ваша основная концепция «История» и «Актив» совершенно правильна.Ваши исторические данные будут более эффективными и гибкими, если они будут храниться в хранилище данных со всеми таблицами измерений и фактов.