Стоит ли опциональные вещи уносить в одно сериализованное поле БД?
Все время решал по-разному, решил уточнить как лучше и практичнее быть с опциональными вещами записи. Допустим, есть модель Новости, у каждой записи этой модели могут быть какие-то опции, которые указываются админ-панели, например, как и где показывать на главной страницы, цвета фона блока и т.д. Для каждой опции добавлять кучу полей в модели/БД накладно, хоть и нужно в админ-панели показывать в отдельных полях, подумал может добавить одно поле Опции записи и сериализовано хранить там такие вещи? при запросе обвернуть в какой класс Опции Новостей и буду с ними играть как будто вытащил по связям.
В общем с одной стороны кучу отдельных полей в БД, с другой одно сериализованное поле. Ну или может опять же отдельная модель/таблица с опциями, которую по связям доставать?
Если по-серьёзному к такому типу задач подходить, то делается несколько таблиц: таблица типов записей, таблица самих записей, таблица параметров, таблица типов данных и таблица значений. Записи ссылаются на типы записей. Таблица параметров тоже ссылается на таблицу типов записей: у каждого типа записей есть свой набор параметров. Каждый параметр имеет свой тип данных. Наконец, таблица значений содержит значения конкретных параметров для конкретной записи. Иногда в таблице значений имеется не одно, а несколько полей значений: для целочисленных, для вещественных, для строковых значений и т.д. - тогда нужное значение выбирается из нужного поля согласно типу данных.
Такое решение очень гибкое, масштабируемое, но более сложное в реализации.
Я обычно так и делаю, храню в json, если полный бардак, то есть куча разных типов данных, в том числе структуры, опции абсолютно разные, могут появиться в любой момент и все это надо как-то связать и, внимание, мне не нужно как-то фильтроваться по этим полям при выборке. В остальных случаях обычно Table per Hierarchy.
