Как создать систему управления версиями/история/ревизию для контента, опубликованного пользователями?

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

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

База данных MySQL

База данных содержит таблицу статей со следующими упрощенными полями:

ARTICLE(id, id_user, title, content, date);

Чтобы реализовать версии версии/истории, я предполагаю, что у нас будет следующая таблица:

REVISION(id, id_article, revision_id_user, id_moderator, revision_date, 
         revision_title, revision_content, revision_description, revision_check);

С отношением: ARTICLE 0,n <---> 1,1 REVISION

Workflow

  • Пользователь создает ARTICLE, который вставлен в таблицу ARTICLE (потрясающе!)

  • Другой пользователь делает обновление этого ARTICLE, это обновление записывается в таблицу REVISION и помещается в очередь для пользователей-модераторов. (revision_check=0).

  • Пользователь модератора проверяет REVISION(revision_check=1), затем ARTICLE(content) получает значение REVISION(revision_content).

Мои вопросы

  • Является ли этот рабочий процесс хорошим способом сделать это? Потому что, я вижу ошибку: если для ARTICLE есть несколько REVISION:

    • Должны ли мы взять содержимое последнего отправленного REVISION или оригинального ARTICLE?
    • Или, если нам нужно заблокировать ревизии, поскольку никакие другие REVISION не могут быть отправлены, пока последнее не проверено.
  • Есть ли способ записи световых версий? Кстати, можно ли вставить в таблицу REVISION только обновленное содержимое через функцию сравнения SQL, PHP или js? И как отобразить его, как это сделать? Потому что я боюсь, что таблица REVISION будет очень тяжелой.

  • Бонус: как SO??

Любая идея, ссылка, источник, плагин (MySQL, PHP 5 и JS/JQuery) будут очень полезны.

Ответ 1

Я не вижу ни одного ответа с плагином для вашего вопроса из-за вашего персонализированного рабочего процесса.

О рабочем процессе ревизии

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

В первой точке, которую я вижу, вы должны заблокировать ревизии до тех пор, пока не будет выполнена ревизия и пока она не будет проверена модератором. Когда он выполняется, добавьте ARTICLE(revision=progress), например, чтобы заблокировать его, и не позволяйте пользователям редактировать статью одновременно, отображая сообщение.

Во-вторых, будьте осторожны, я считаю, что автор статьи мог обновить ее без какого-либо замедления. По этой причине вам придется также установить ARTICLE(revision=progress), в то время как автор обновляет собственную статью.

О записи легкой версии ревизий в db

Вы можете создать сумасшедшую функцию в php (или другом), которая создает массив для каждого изменения, например:

array('1'=>array('char_pos'=>'250','type'=>'delete','length'=>'25','change'=>''),
'2'=>array('char_pos'=>'450','type'=>'insert','length'=>'16','change'=>'some text change'),
...);

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

Я думаю, что нет пути для управления версиями с MySQL. Вы можете что-то сделать для управления версиями с ORM, как PROPEL, но я не думаю, что результат будет тем, что вы ожидаете...

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

О дисплее сравнения

Вы можете использовать плагин Diff-Match-Patch, чтобы освежить обновления между двумя содержимыми, "отличия" здесь. Я думаю, что SO использует Beyond compare (или подобное) для изменения hilight между версиями.

Чтобы узнать больше о технологиях SO, вы можете посмотреть эту страницу.