Порассуждаю о дополнительных блоках свойств для поста (надо заметить, что все предыдущие рассуждения, несмотря на некую туманную абстракцию, были все успешно реализованы). Что имеем на сегодня: от поста можно порождать дочерние классы и это работает напримере тикет системы. Все отлично. Один недостаток - жесткая иерархия. Если хочется добавить новых свойств, то придется делать новый дочерний класс со своей таблицей. В существующем коде уровень иерархии ограничен одним уровнем (можно неограниченно, но тогда придется самому реализовывать алгоритмы запроса к бд дополнительных данных из таблиц). Второй вариант - сделать alter table для постов. Может сработать для одинарных типов данных. Собственно, веду к тому, что уже придумал модель.

Пост будет хранилищем данных запрошенных из бд, а вот его данные будут обрабатывать объекты (соседи - сателлиты). При запросе свойства у поста будет проход по списку соседей. Количество соседей может быть произвольным. По умолчанию - один глобальный сосед. Сосед будет прокладкой между данными полученными из бд и постом и наоборот - изменение свойств приводит к изменению данных непосредственно готовых для прямого запроса к бд. Для простых типов данных (чисел и строк) трансформации не требуется. Для массивов и дат необходимо. Массив в бд - строка id разделенная запятыми, время преобразовывать к unix timestamp. Также следует признать плохим типом булевый тип: он для бд является числом и не является перечислимым (enum) типом. Следует признать, что я допустил ошибку планирования, применив булев тип к полям бд. Надо будет его преобразовать к enum.

В такой модели все отлично, за исключением одной штуки - будет ли известно количество соседей при создании поста. Хорошим был бы ответ - да и тогда придется дергать данные для всех соседей. Проблема может возникнуть когда нам потребуется пост для манипуляций с парой свойств, но при этом будет запрашиваться из бд куча данных для соседей. Каким образом отделить одно от другого мне пока не представляется возможным, либо попытаться формализовать пост таким образом, что будет спецкласс со всеми загруженными соседями и одинарный пост без соседей.

Небольшое отступление - для чего нужны соседи. Делаем магазин с товарами - сосед это свойства товара. Данные изолированы от поста и применяются для управления товаром как тикетом в тикет системе. Все ок. Но проблема в том, что универсальный товар не может содержать всех свойств любого товара. Например - одежда и автомобили. Для одежды нужны фасон, материал, мужск/женск, а у автомобиля мощность двигателя, потребление бензина. Свойства автомобилей и одежды не пересекаются. Для каждого из них своя таблица и свой сосед для поста.

Попытаюсь расписать для полного поста (промежуточный вариант с одинарным постом - свойства по запросу - об этом после). В таблице постов нужно имеет дополнительное свойство или возможно использовать существующее в сегодняшней модели - имя класса полного поста. Это не выгодно - декларировать придется для всех сочетаний соседей, что не имеет смысл. Логично иметь массив (или id на такой массив) на соседей. В редакторе поста (или же ином редакторе - редактор товара) показывать чекбоксы на соседей. Да, сделаю синхронизованный массив (как с метками/рубриками). Остается открытым вопрос об общем количестве соседей в системе. Для нескольких десятков городить отдельную таблицу смысла не имеет. С другой стороны нужно взаимное отслеживание друг друга -соседей и постов для синхронизации данных. Я имею в виду добавление/удаление соседа в системе. Собственно ограничивать количество соседей в системе не имеет смысла, хотя с трудом представляют соседей более десятка на одном сайте.

Свойства по запросу. Вернее сосед по требованию: у поста запрашивается свойства, у текущих соседей свойство не найдено, тогда проверяется есть ли такое свойство у не загруженных соседей. технически вопрос должен звучать так: запрошены ли данные из таблицы для этого соседа. Тоже не верно - создать соседа и проверить имя свойства у соседа, если у него нет данных, то он запрашивает их в бд. Чтобы оптимизировать и исключить серии одиночных запросов к бд, сосед может запрашивать бд для остальных уже загруженных постов, для которых применим этот сосед. Таким образом получается, что класс соседа обязан знать заранее имена всех своих свойств. Это не фатально и не перегрузит систему. Вместе с именами свойств можно хранить инфу о типе данных этого свойства: число, строка, время, булев.

Мне больше нравится последний вариант, так как при массовом запросе постов в бд (как правило анонсы на одной странице - один или несколько десятков) нагрузка на бд останется прежней, хотя теоретически все можно было бы вложить в один запрос.