Версионность и модерация данных?

Question

[Денис Олешкевич]

Здравствуйте!


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

id<br/>
*name<br/>
*surname<br/>
jabber<br/>
skype

Требуется сделать следующее:

1. Хранить историю правок по каждому пользователю
   
2. Поля помеченные звездочкой являются модерируемыми, и изменения данных в них должен подтверждать администратор.
   
3. Иногда будет требоваться откат к предыдущим ревизиям.
   

Не могу выбрать как хранить эти ревизии, придумал три способа:

1. Хранить данные и ревизии в одной таблице. В этом случае не требуется создавать таблицы, но таблица будет заполнена ревизиями, которые редко когда нужны.
   
2. Хранить ревизии в отдельной таблице. В этом случае не понятно как должны хранится ревизии по немодерируемым полям созданные после ревизии по модерируемым полям.
   
3. Хранить ревизии по модерируемым и немодерируемым полям в двух разных таблицах. В этом случае потребуется делать дополнительную логику по разнесению данных в две таблицы. А сама ревизия становится не атомарной.
   

Какой способ будет наиболее правильным?

Answer 1

[philpirj]

Насколько я понял, больше всего вас смущает кейс, когда пользователь изменил модерируемое поле, модератор ещё не успел подтвердить, и потом пользователь сменил немодерируемое поле и ждёт появления этого изменения сразу. В таком случае не вижу другого варианта, как 3, то есть раздельное хранение модерируемых и немодерируемых полей. Изменение логики при этом минимально.

О какой атомарности ревизии идёт речь, какой кейс рассматриваете? Когда пользователь в первый заход поменял и модерируемое и немодерируемое поля, а во второй — только немодерируемое? Вот как раз при совместном хранении (варианты 1 и 2) и будет возникать неоднозначность, то есть в случае если модератор подтверждает изменение 1, то данные какой записи считать актуальными? Тут два варианта — вносить во запись при втором изменении в модерируемые поля либо изначальные данные, либо данные из первого изменения. Первый вариант ломается, если модератор подтверждает запись, а второй — если не подтверждает. Надеюсь, путно объяснил.

Answer 2

[korvindest]

Опишу как сделано в одной из систем, которую я дорабатываю.

Есть две таблицы:
Основная — хранит в наборе полей самую последнюю версию записи.
Таблица коррекций — хранит тот же набор полей + Дату изменения, пользователя(сделавшего изменение), и флаг что запись удалена. В вашем случае во вторую таблицу стоит добавить флаг, что данные подтверждены.

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

Answer 3

[dbmaster]

В зависимости от инструментов:

* посмотрите Partitioning — база данных сама всё сделает
stackoverflow.com/questions/102278/active-flag-or-not

* 2й вариант может работать с таблицами одинаковыми полями для облегчения жизни

Answer 4

[mark_ablov]

2 вариант имхо лучший.
Дабы избежать коллизий того типа о котором вы упомянули достаточно хранить только измененное поле/поля в одной записи в таблице ревизий, а остальные — NULL.