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

Question

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

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

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

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

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

Спасибо

Answer 1

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

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

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

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

Answer 2

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

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

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

Answer 3

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