modx и проблема универсальной БД
Не даёт покоя вот такой вопрос. Все существующие CMS/CMF реализуют архитектуру универсальной БД, когда все данные (ресурсы/страницы) хранятся в одной таблице, а их индивидуальные характеристики — в другой таблице. С одной стороны, это позволяет реализовать более простую логику обработки этих данных и предоставляет возможность управлять этими данными в админке. Но главная проблема универсальной БД — это чрезвычайная сложность запросов с участием индивидуальных характеристик сущностей. Для выборки с участием TV-полей приходится каждую TV подключать через отдельный join. А для фильтрации запроса по множественным TV приходится использовать LIKE (сплошной прогон по всем строкам => очень медленное выполнение). Для обхода этих проблем можно использовать 3 манёвра:
- Для реализации быстрой выборки TV-полей — хранить все TV в дополнительном поле таблицы ресурсов (после выборки — «распаковывать» их)
- Для реализации быстрой фильтрации по TV — дублировать некоторые TV в таблицу ресурсов (и создать для них индексы)
- Для быстрой фильтрации по множественным TV (с идентификаторами связанных ресурсов) использовать 3-ю таблицу для связей ресурсов друг с другом Но эти обходные манёвры усложняют логику и являются лишь частным решением проблем. Вопросы:
- В компонентах, которые вы разрабатываете, — новые сущности реализованы в виде ресурсов (для каждого — свой class) или на базе собственных таблиц?
- Если все сущности предметной области проекта реализовывать на собственных таблицах, то в этом случае какие преимущества остаются у modx перед классическими фреймворками? Ведь и там, и там придётся самостоятельно реализовывать функционал админки для работы с этими сущностями + строить ORM-модель для этих сущностей. Более того, для таких таблиц не получится задействовать стандартные механизмы modx (friendly url, плагины, права на TV, поиск в админке и пр.). И вообще, не получится отображать эти страницы, т.к. ядро modx рендерит только ресурсы. Т.е. если все сущности реализовать на собственных таблицах, нужен ли будет modx вообще?
если все сущности реализовать на собственных таблицах, нужен ли будет modx вообще? Это вопрос вкуса и навыков. В MODX встроена ExtJS, которая великолепно справляется со всеми задачами.
Еще кэширование из коробочного функционала забыли — очень вкусная вкусная функция. Когда наша студия только начинала делать новые сайты на MODX, весь дополнительный функционал делали в своих таблицах, и интернет магазин делали где товары и характеристики хранились в отдельных таблицах. Потом поняли, что от MODX у нас только авторизация и текстовые страницы, и даже пагинацию на страницах товаров делали «руками». Теперь используем MODX API по полной, работать легче, а значит за тот же срок можно реализовать более сложный функционал. Все сущности — в ресурсах.
весь дополнительный функционал делали в своих таблицах, и интернет магазин делали где товары и характеристики хранились в отдельных таблицах. У меня к вам 2 вопроса:
- Когда товары с характеристиками вы хранили в отдельных таблицах, вы дружественные URL не использовали? Т.е. у вас была одна страница-ресурс + GET-параметр запроса, который определял отображаемый товар. так?
- Сейчас, когда все сущности вы храните в ресурсах, как вы выполняете фильтрацию/сортировку по TV? Каждый TV подключаете отдельным JOIN'ом?
На самом деле можно использовать классы для расширения в связке с VirtualPage и тогда будет работать кэш. Если нужен пример то установить VirtualPage настройте его и для ресурса назначенном для VirtualPage используйте class_key расширяющего класса. Получиться пример тоже самое что у товаров для minishop. Только чпу будет контролировать VirtualPage а не modx ну и соответственно чпу уже придется самим генерировать и записывать в modx чтобы потом можно было найти страницу
Я давным давно для решения этого вопроса разработал modResourceField.
Коли упомянут компонент, приведу ссылку: VirtualPage, обсуждение Насколько я понимаю, этот компонент принимает набор URL'ов, удовлетворяющих регулярному выражению, и возвращает ресурс, чанк или результат выполнения сниппета. При использовании собственных таблиц имеют место следующие проблемы:
- friendly url
- стандартный механизм кэширования
- редактирование ресурсов и TV в админке
- права на ресурсы и TV
- поиск в админке
- компоненты не будут работать с «виртуальными» ресурсами. А вернее, работать будут, но только с ресурсом-шлюзом ... Обозначенный плагин решает только две проблемы: 1 — вместо параметров запроса возможно включить ключ в основную часть URI (полезно для SEO) 2 — компонент добавляет ключ-префикс к кэшу ресурса (в итоге у каждой «виртуальной» страницы — свой кэш)
Дублирование/хранение всех/некоторых TV в таблице ресурсов — решает проблему медленной фильтрации/сортировки по «одиночным» TV-полям и частично — проблему медленной выборки TV-полей. Но не решает проблему фильтрации по множественным TV.
У меня к вам 2 вопроса: Отвечаю:
- Да, одна страница + get параметры, ЧПУ не использовались.
- Используем tagmanager2 вроде так называется, если для TV нужны прямо фильтры. Для магазинов теперь уже mFilter, но там и не TV для параметров используются. А если просто при вызове сниппета нужно что-то фильтровать, то все стандартно, &includeTVS, &where, вроде бы там (pdoTools). Не нашел рабочий пример под рукой, завтра найду приведу сюда код. https://modx.com/extras/package/tagmanager2 Последний раз когда мы им пользовались, было 5тыс товаров и около 15 разных TV-параметров. Могу ошибаться, но вроде было достаточно быстро.
Но не решает проблему фильтрации по множественным TV. Таки да, не решит, просто потому что мускул не умеет массивы хранить. В таких случаях я тогда юзаю только дополнительные таблицы. Кстати, MigxDB в этом сильно помогает.