Хочу поинтересоваться, почему не в LS, не в Альто нет хранения истории редактирования материалов как например в том же WP?
Это связано с тем — что бы не раздувать БД? или другая причина?
И сильно ли вообще утяжеляет работу движка/сайта возможность хранения истории редактирования?
октября
04
2014
+1
Что по поводу утяжеления сайта. Смотря, что будет храниться в истории. Думаю, если будет храниться только текст топика, и это сделать в отдельной таблице, то это никак не отяжелит работу сайта в момент показа топика пользователю.
Думаю, что можно сделать плагин, реализующий этот функционал.
Думаю, можно базу спроектировать так, чтобы ведение такой истории не отразилось на быстродействии. Но по объему раздуваться база, конечно, будет. И чем активнее юзеры на сайте, тем быстрее она будет раздуваться.
Какие для этого требования к базе нужно предъявить при реализации такого плагина? — в общих чертах не обозначите?
Ну да, тут есть над чем подумать, что бы сократить количество версий топика… Кому-то запрещать редактирование на первых порах, кому-то разрешать по запросу и т.п.
Если исходим из того, что нам не нужно будет выполнять поиск по контенту, хранимому в истории (т.е. кто, когда и что менял — это да, а вот прямо по самому контенту — нет), то заводим таблицу для хранения историй изменения сущностей примерно такой структуры:
* history_id
* target_type
* target_id
* history_user_id
* history_date
* history_data
И пишем метод, которой будем вызывать перед обновлением каждой сущности, примерно так:
А в методе дергаем нужную сущность и сохраняем ее сериализованные данные в этой таблице.
Ну и надо подумать, как метить сущности, у которых есть история. И тут ведь такое дело — при обычном отображении сущностей нам ведь неважно, есть история или нет, поэтому штатный вывод можно оставить таким же, какой и был, вообще без единого дополнительно запроса к базе. А вот при редактировании показывать, то у топика есть история изменений. И в даминке тоже можно это показывать.
Вот, как-то так, наверное