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

Question

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

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

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

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

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

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

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

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

Answer 1

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

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

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

Answer 2

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