Не даёт покоя вот такой вопрос. Все существующие CMS/CMF реализуют архитектуру универсальной БД, когда все данные (ресурсы/страницы) хранятся в одной таблице, а их индивидуальные характеристики — в другой таблице. С одной стороны, это позволяет реализовать более простую логику обработки этих данных и предоставляет возможность управлять этими данными в админке. Но главная проблема универсальной БД — это чрезвычайная сложность запросов с участием индивидуальных характеристик сущностей. Для выборки с участием TV-полей приходится каждую TV подключать через отдельный join. А для фильтрации запроса по множественным TV приходится использовать LIKE (сплошной прогон по всем строкам => очень медленное выполнение). Для обхода этих проблем можно использовать 3 манёвра:
если все сущности реализовать на собственных таблицах, нужен ли будет modx вообще? Это вопрос вкуса и навыков. В MODX встроена ExtJS, которая великолепно справляется со всеми задачами.
Еще кэширование из коробочного функционала забыли — очень вкусная вкусная функция. Когда наша студия только начинала делать новые сайты на MODX, весь дополнительный функционал делали в своих таблицах, и интернет магазин делали где товары и характеристики хранились в отдельных таблицах. Потом поняли, что от MODX у нас только авторизация и текстовые страницы, и даже пагинацию на страницах товаров делали «руками». Теперь используем MODX API по полной, работать легче, а значит за тот же срок можно реализовать более сложный функционал. Все сущности — в ресурсах.
весь дополнительный функционал делали в своих таблицах, и интернет магазин делали где товары и характеристики хранились в отдельных таблицах. У меня к вам 2 вопроса:
На самом деле можно использовать классы для расширения в связке с VirtualPage и тогда будет работать кэш. Если нужен пример то установить VirtualPage настройте его и для ресурса назначенном для VirtualPage используйте class_key расширяющего класса. Получиться пример тоже самое что у товаров для minishop. Только чпу будет контролировать VirtualPage а не modx ну и соответственно чпу уже придется самим генерировать и записывать в modx чтобы потом можно было найти страницу
Я давным давно для решения этого вопроса разработал modResourceField.
Коли упомянут компонент, приведу ссылку: VirtualPage, обсуждение Насколько я понимаю, этот компонент принимает набор URL'ов, удовлетворяющих регулярному выражению, и возвращает ресурс, чанк или результат выполнения сниппета. При использовании собственных таблиц имеют место следующие проблемы:
Дублирование/хранение всех/некоторых TV в таблице ресурсов — решает проблему медленной фильтрации/сортировки по «одиночным» TV-полям и частично — проблему медленной выборки TV-полей. Но не решает проблему фильтрации по множественным TV.
У меня к вам 2 вопроса: Отвечаю:
Но не решает проблему фильтрации по множественным TV. Таки да, не решит, просто потому что мускул не умеет массивы хранить. В таких случаях я тогда юзаю только дополнительные таблицы. Кстати, MigxDB в этом сильно помогает.