Управляемая версией база данных с эффективным использованием diff

Question

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

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

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

Моя последняя идея немного менее традиционна. Поскольку исторические данные будут использоваться для составления отчетов, пользователям веб-интерфейса не требуется быстрый доступ. Я думаю, что мой БД не может иметь исторических данных в нем. БД представляет только текущее состояние. Затем ежедневно вся база данных может быть загружена в объекты (количество пользователей / данных относительно невелика), а затем сериализована в нечто вроде XML или JSON. Эти файлы могут быть переданы в предыдущий день и сохранены. На самом деле SVN может сделать это для меня. Когда я хочу получить данные за определенный прошедший день, система должна извлечь версию для этого дня и десериализовать в объекты. Это, очевидно, дорогостоящая операция, но производительность здесь не так важна. Я рассматриваю возможность использования LINQ для этого, что, я думаю, упростит ситуацию. Процедура сериализации должна быть довольно организованной, чтобы diff работал хорошо.

Какой подход вы бы выбрали?

Спасибо

Answer 1

Если вам интересно, как ревизии данных хранятся в реляционных базах данных, я бы посмотрел, как это делают вики.

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

Рассмотрим базу данных Википедии схема .

Answer 2

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

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

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

Я думаю, что так оно и есть.

Answer 3

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