Классическая схема физического хранения изображений галереи — набор папок для каждого ресурса, внутри — графические файлы. Для отображения на сайте изображений некоторого ресурса просто-напросто берём графические файлы из папки, соответствующей нашему ресурсу. Просто и логично.

Но в моём случае: а) каждый графический файл может быть связан с одним и более ресурсами одновременно (а в некоторые моменты времени может быть не связан ни с одним из ресурсов) б) каждый графический файл имеет с десяток характеристик (по которым будет выполняться сортировка/фильтрация) в) каждый графический файл будет иметь комментарии пользователей г) каждый графический файл будет иметь свою собственную страницу на сайте (с описанием, характеристиками, комментариями и пр.)

Очевидно, что простым хранением графических файлов в тех или иных папках здесь не обойтись — нужно ещё хранить данные о каждом изображении. Возможны 2 варианта:

ВАРИАНТ 1. Для каждого графического файла создаётся отдельный ресурс (типа «Документ» или «Статический ресурс») с TV-параметрами

Преимущества:

1. Обслуживание, управление и формирование характеристик изображений выполняется стандартными средствами modx (характеристики, вычисляемые автоматически путём анализа изображения, легко реализуются на уровне плагинов)
2. Загрузка страниц, посвящённых изображениям, будет выполняться без каких-либо проблем стандартными средствами modx (как и страницы любых других ресурсов)
3. Легко прикрутить готовые компоненты для работы с комментариями (при хранении в собственных таблицах придётся писать свою систему комментариев)
4. Число просмотров, число комментариев и прочие realtime-характеристики будут обрабатываться теми же средствами, которые работают в отношении прочих ресурсов

Недостатки:

1. Быстрее себя проявит проблема большой карты ресурсов
2. Чуть медленнее будет выполняться фильтрация и сортировка по TV этих изображений. Впрочем это проблема/особенность архитектуры modx (а вернее, т.н. универсальных БД), а никак не проблема выбранного варианта хранения данных изображений

ВАРИАНТ 2. Информация о каждом изображении хранится в отдельной таблице

Преимущества:

1. Проблема большой карты ресурсов будет проявляться в существенно меньшей степени
2. Чуть быстрее будет работать фильтрация и сортировка по характеристикам изображений

Недостатки:

1. Интерфейс для формирования и просмотра характеристик изображений придётся разрабатывать свой
2. Систему комментариев придётся разрабатывать свою
3. Существенно урезаются стандартные возможности modx по работе с изображениями на уровне чанков и сниппетов (например, использование тегов [[~id]])
4. Для изображений придётся разрабатывать отдельную систему управления числом просмотров, числом комментариев и прочими realtime-характеристиками. Либо расширять возможности существующей системы (работающей со стандартными ресурсами modx) в направлении использования пользовательских таблиц.

— Склоняюсь к первому варианту. В случае с отдельной таблицей дофига всего писать придётся (и всё написанное придётся постоянно корректировать синхронно с изменениями архитектуры/ядра и логики работы modx).

Ваше видение ситуации? Собственно, интересует не только оптимальный с вашей точки зрения вариант, но и другие ньюансы и потенциальные проблемы (в обоих вариантах), которые я не учёл.