Как лучше организовать версионность документов в yii2?
Необходимо сделать возможность "отката" документов в системе и просмотра версий изменений.
В приложении есть несколько сущностей (моделей и таблиц), у которых надо сохранять версии после редактирования (к примеру "новости" и "статьи").
Сейчас видится два варианта. Первый - тупо делать в текущей таблицы копию записи и ставить у неё флаг типа notshow. Вариант простой, всё решается в пределах одной модели и контроллера, но не нравится то, что таблица будет сильно распухать от большого кол-ва версий. И всякие поиски будут тормозить (расчёт идёт на несколько миллионов "оригинальных" записей, т.е. с версиями это всё может увеличиться еще в десятки раз).
Второй - сделать вторую модель с таблицей, которые будут копировать почти весь функционал оригинальной модели, за исключением условного поля original_id, которое будет ссылать на запись в оригинальной таблице. В этом варианте не нравится куча кода, который будет дублировать код из оригинальной модели.
Что если разделить содержание статей и информацию о статье? Например, будет таблица содержаний статей (некие body со всей статьей), и будет таблица заголовков статей. Заголовки статей связаны с содержаниями статей, при этом у содержаний есть флаг is_active.
таким образом, SELECT * from headers, topics WHERE topics.id_header = header.id AND topics.is_active = 1; - выведет список всех заголовков и содержимых статей с последней версией.
Decadal: ну там на самом деле еще языки есть. Т.е. фактически документ состоит из двух таблиц - в одной общая информация (но которая тоже может меняться), а в другой языковые версии.
hostadmin ... AND lang = 'ru'
По сути, языковые версии это такое же версионирование, которое разрабатываете вы. Выбранный язык == выбранная версия. Как у вас сделаны языки, так имеет смысл сделать и версионирование. Хотя так, вслепую конечно сложно сказать, как лучше.
А новую модель наследовать от первой. Учите ООП и будет вам счастье.
Пример:
// Обычная модель для работе с обычной таблицей
class News extend ActiveRecord
{
public static function indexName()
{
return '{{%news}}';
}
}
// Модель для работы с архивами
class ArchiveNews extend News
{
public static function indexName()
{
return '{{%archive_news}}';
}
}
Естественно весь функционал модели News будет доступен и справедлив для ArchiveNews. Останется только где-то переписать / расширить некоторые методы для работы с новым полем 'original_id'.
Шутите? Ни в коем случае так делать нельзя, тем более для таблиц с миллионами записей!
Естественно надо делать вторую таблицу.
А новую модель наследовать от первой. Учите ООП и будет вам счастье.
Пример:
// Обычная модель для работе с обычной таблицей
class News extend ActiveRecord
{
public static function indexName()
{
return '{{%news}}';
}
}
// Модель для работы с архивами
class ArchiveNews extend News
{
public static function indexName()
{
return '{{%archive_news}}';
}
}
Естественно весь функционал модели News будет доступен и справедлив для ArchiveNews. Останется только где-то переписать / расширить некоторые методы для работы с новым полем 'original_id'.
Средний
