Бекапы версий контента при создании статьи как реализовать? (PHP, MySql)?

Question

[Teutonick]

К примеру в вордпрессе есть такая фишка



То есть на каждую статью приходится несколько версий, сохраненных через некоторый интервал с возможностью отката на каждую из них. Подскажите пожалуйста, как это грамотно реализовать средствами PHP и MySQl! Спасибо

Comments

[Teutonick]

Я имел ввиду не бекап сайта, а версионность единичной статьи. Что то типа Истории в фотошопе, то в любой момент можно откатится на любой из 20 шагов назад.

Answer 1

[LIAL]

targz + cron

Comments

[Teutonick]

большое спасибо за наводку, если кого не затруднит сделать более полный ответ или дать ссылочку на пример реализации

Answer 2

[LIAL]

Это сокорее фича системы а не PHP+MySQL (хотя думаю и из под них прикрутить можно.)
У меня так сайт бэкапится + база:

1. tar -cvzf /_mybackups/NAME_www.tgz /home/NAME/public_html /home/NAME/includes — те каталоги которые мне нужны сворачиваю в архив

2. mysqldump -h localhost -u LOGIN PASSWORD -d DATABASE > /_mybackups/db_service.sql — снимаю дамп с базы

3. tar -cvzf /_mybackups/db_service.tgz /_mybackups/db_service.sql — базу в архив

4. rm /_mybackups/db_service.sql — удаляю дамп

Таким образом на выходе архив с БД и с сайтом

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

Comments

[So1]

это пример того, как нельзя делать

[mitnlag]

-1

Answer 3

[Александр]

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

Простейшая структура с минимальным кол-вом необходимых полей выглядит так:
— article_id (не уникальный)
— timestamp
— content

Соответственно при сохранении добавляем новую строку с тем же ID, но более свежим таймстампом. При выборке — берем наиболее свежий (запросы с группировкой, либо дополнительное обновляемое поле с флажком для пефоманса).

Comments

[So1]

а так ваша таблица будет в 5 раз больше, чем нужно и это уж точно не эффективно :)

[Teutonick]

Я почему то думал что это делается именно так ))) сомневаюсь что тот сайт, на котором я это видел, использует КРОН и т.п.

Тем более я имел ввиду не бекап сайта, а версионность единичной статьи. Что то типа Истории в фотошопе, то в любой момент можно откатится на любой из 20 шагов назад.

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

Спасибы всем.

[Александр]

> таблица будет в 5 раз больше, чем нужно
Чем нужно кому? Заказчик хочет хранить версии, значит нужен доступ к ним. Соответственно нельзя сказать, что связанная с хранением прошлых версий информация избыточна.

> не эффективно
Я описал простейший вариант. Разумеется его можно оптимизировать по различным парметрам:
1. Занимаемому объему
2. Времени сохранения
3. Времени выборки
4. Времени разработки :)
5.…

Предложенный вариант оптимизирован по п.4 :)

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

Так что в некоторых случаях достаточно этого хеллоувёлдного варианта, не так ли? :)

[Владимир Чернышев]

По времени разработки, по-моему, проще реализовать из двух таблиц:

article:
id:…
current_version_id:…
… #не версионнируемые поля

article_version:
id:…
article_id:…
timestamp:…
title:…
body:…
… #другие версионнируемые поля

По крайней мере не надо думать о получении неуникального id, а довериться СУБД

Вообще, по-моему, минимальное время разработки получается при полной нормализации БД, а денормализация (или не до конца доведённая нормализация) это уже оптимизация других параметров (или раздолбайство :) )

Answer 4

[MastaEx]

А я почему-то уверен, что там просто сохраняются diff'ы.
Так что берете wordpress и смотрите как именно они сохраняются.

Comments

[So1]

diff'ы — это пример того, как нужно делать

[mitnlag]

+1

Answer 5

[shelestov]

Храните статьи в Subversion