Хранение истории редактирования

Хочу поинтересоваться, почему не в LS, не в Альто нет хранения истории редактирования материалов как например в том же WP?
Это связано с тем — что бы не раздувать БД? или другая причина?
И сильно ли вообще утяжеляет работу движка/сайта возможность хранения истории редактирования?

5 комментариев

+1
Почему подобный функционал еще не реализован? Точного ответа у меня нет. Однако, вполне возможно, потому, что не было цели создать подобный функционал.
Что по поводу утяжеления сайта. Смотря, что будет храниться в истории. Думаю, если будет храниться только текст топика, и это сделать в отдельной таблице, то это никак не отяжелит работу сайта в момент показа топика пользователю.
Думаю, что можно сделать плагин, реализующий этот функционал.
+1
Все так. За все время работы с ЛС и с Альто я только одного человека встречал, который считал, что история редактирования должна быть в CMS прямо из коробки. Я же лично не вижу в этом потребности. Поэтому, как и обычно в подобных случаях, склонен отдать это на откуп плагинам.

Думаю, можно базу спроектировать так, чтобы ведение такой истории не отразилось на быстродействии. Но по объему раздуваться база, конечно, будет. И чем активнее юзеры на сайте, тем быстрее она будет раздуваться.
0
склонен отдать это на откуп плагинам.
Надо будет подумать в этом направлении)

Думаю, можно базу спроектировать так, чтобы ведение такой истории не отразилось на быстродействии.
Какие для этого требования к базе нужно предъявить при реализации такого плагина? — в общих чертах не обозначите?

Но по объему раздуваться база, конечно, будет. И чем активнее юзеры на сайте, тем быстрее она будет раздуваться.
Ну да, тут есть над чем подумать, что бы сократить количество версий топика… Кому-то запрещать редактирование на первых порах, кому-то разрешать по запросу и т.п.
0
Внимательно не думал, но я бы пожалуй, таким путем пошел бы, чтоб, при желании можно было хранить историю изменения любой сущности — топик, комментарий, да хоть профиль юзера или даже сущности сторонних плагинов, напр., товаров, информации о компании и пр.

Если исходим из того, что нам не нужно будет выполнять поиск по контенту, хранимому в истории (т.е. кто, когда и что менял — это да, а вот прямо по самому контенту — нет), то заводим таблицу для хранения историй изменения сущностей примерно такой структуры:
* history_id
* target_type
* target_id
* history_user_id
* history_date
* history_data
И пишем метод, которой будем вызывать перед обновлением каждой сущности, примерно так:
$this->PluginHistory_History_Insert('topic', $iTopicId);
А в методе дергаем нужную сущность и сохраняем ее сериализованные данные в этой таблице.

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

Вот, как-то так, наверное
0
Однако, вполне возможно, потому, что не было цели создать подобный функционал.
Ну я в принципе так и думал:) Но решил уточнить, мало-ли это связано с производительностью.
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.