Вопросы специалистов

Организация хранения данных об изображениях галереи

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

Если речь о десятках и более тысяч документов, то это поможет: habrahabr.ru/post/253737/

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

2.Чуть медленнее будет выполняться фильтрация и со

Здравствуйте, Николай. В тему по Вашей ссылке задам вопрос. Недавно реализовывал то, о чём Вы там писали. Возможности значительно расширяются с подобным подходом. БлагоДарю Вас от всей Души! Однако, не удалось обращаться к своим данным из таблицы site_content, как к стандартным, через плейсхолдеры. К примеру так [[*logo]], пришлось писать сниппет, который восполнил мои нужды (подтягивал данные полей отмеченных в параметре у указанного ресурса). Отсюда вопрос: так и должно быть, или я что-то не так сделал?
 

P.S.: Немножко дописывал Ваш плагин, который Вы указали на Хабре. Хотел сначало выложить куда-то и скинуть Вам, а потом подумал — зачем Вам нужен мой ГК. :) И раз уж пишу тут, всё-таки предложу. Если интересно — напишите, я выложу куда-нибудь.

Здравствуйте, Николай. В тему по Вашей ссылке задам вопрос. Недавно реализовывал то, о чём Вы там писали. Возможности значительно расширяются с подобным подходом. БлагоДарю Вас от всей Души! Однако, не удалось обращаться к своим данным из таблицы site_content, как к стандартным, через плейсхолдеры. К примеру так [[*logo]], пришлось писать сниппет, который восполнил мои нужды (подтягивал данные полей отмеченных в параметре у указанного ресурса). Отсюда вопрос: так и должно быть, или я что-то не так сделал? P.S.: Немножко дописывал Ваш плагин, который Вы указали на Хабре. Хотел сначало выложить куда-то и скинуть Вам, а потом подумал — зачем Вам нужен мой ГК. :) И раз уж пишу тут, всё-таки предложу. Если интересно — напишите, я выложу куда-нибудь.

Здравствуйте, Николай. В тему по Вашей ссылке зада

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

Пожалейте тех, кому потом придется с такой галереей работать.

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

ВАРИАНТ 1. Для каждого графического файла создаётс

К примеру так [[*logo]], пришлось писать сниппет, который восполнил мои нужды (подтягивал данные полей отмеченных в параметре у указанного ресурса). Отсюда вопрос: так и должно быть, или я что-то не так сделал?

Так вы в смарти-шаблоне попробуйте прописать {$modx->resource->logo}. Так же getdata-процессоры вернут массивы данных ресурсов, содержащих элемент logo. Собственно, мы плейсхолдеры особо не юзаем.

К примеру так [[*logo]], пришлось писать сниппет, который восполнил мои нужды (подтягивал данные полей отмеченных в параметре у указанного ресурса). Отсюда вопрос: так и должно быть, или я что-то не так сделал? Так вы в смарти-шаблоне попробуйте прописать {$modx->resource->logo}. Так же getdata-процессоры вернут массивы данных ресурсов, содержащих элемент logo. Собственно, мы плейсхолдеры особо не юзаем.

К примеру так [[*logo]], пришлось писать сниппет, 

C другой стороны, если «каждый графический файл будет иметь свою собственную страницу на сайте (с описанием, характеристиками, комментариями и пр.)», то разве это галерея? В моем понимании, в галерее создаются изображения, а тут получается, что создаются страницы.

C другой стороны, если «каждый графический файл бу

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

Но этот вариант не всегда реализуем. Как, например, в моём случае.
 У меня более десяти типов ресурсов, у каждого — по 15-20 TV. Итого — сотни TV. Сортировка и фильтрация выполняется по большинству из них. Да, можно все эти TV (по которым выполняется сортировка и фильтрация) автоматом закинуть в (site_content) и индивидуально типизировать на основе характеристик TV. И сделать всё это программно (имя поля = tv_{id}). В mySQL допускается 4 тысячи полей в таблице. Этого с головой хватит и на текущий, и на будущий функционал. Но проблема в том, что работать с этими полями без индексов не имеет смысла, а максимально допустимое число индексов в таблице mySQL — 64. Вот это ограничение и является определяющим. Даже если для некоторых полей создавать составные индексы, всё равно индексов понадобится более 100. К тому же со временем функционал будет только расширяться, добавляться новые типы ресурсов и новые TV-поля.
 

Сейчас у меня реализован следующий вариант:
 а) все TV-поля дублируются в поле (properties) таблицы ресурсов (в формате json) — это поле используется для выборки TV
 б) при фильтрации и сортировках подключаются через JOIN только те TV, которые участвуют в этих фильтрах/сортировках (как правило, их не более 3 за раз, а 3 JOIN'а выполняются вполне себе быстро)
 в) в случаях, когда ресурс имеет большое количество TV, а в конечной выборке необходимо получить 2-3 TV-ки, эти TV join'ятся (так быстрее: на json-декодирование большого числа TV нужно время), в остальных случаях для выборки использую поле (properties) с последующим json-декодированием

Если речь о десятках и более тысяч документов, то это поможет: habrahabr.ru/post/253737/ Вариант хороший. На первый взгляд, даже идеальный:
 а) никакие join'ы не требуются
 б) каждое поле индивидуально типизировано и проиндексировано — как следствие, сортировка и фильтрация будут выполняться максимально быстро и корректно (для строковых значений сравнение строковое, для числовых — числовое)
 в) данные занимают меньше места за счёт индивидуальной типизации (верно, только если оригинальные значения TV-параметров из стандартной таблицы с TV будут удаляться) Но этот вариант не всегда реализуем. Как, например, в моём случае.
 У меня более десяти типов ресурсов, у каждого — по 15-20 TV. Итого — сотни TV. Сортировка и фильтрация выполняется по большинству из них. Да, можно все эти TV (по которым выполняется сортировка и фильтрация) автоматом закинуть в (site_content) и индивидуально типизировать на основе характеристик TV. И сделать всё это программно (имя поля = tv_{id}). В mySQL допускается 4 тысячи полей в таблице. Этого с головой хватит и на текущий, и на будущий функционал. Но проблема в том, что работать с этими полями без индексов не имеет смысла, а максимально допустимое число индексов в таблице mySQL — 64. Вот это ограничение и является определяющим. Даже если для некоторых полей создавать составные индексы, всё равно индексов понадобится более 100. К тому же со временем функционал будет только расширяться, добавляться новые типы ресурсов и новые TV-поля. Сейчас у меня реализован следующий вариант:
 а) все TV-поля дублируются в поле (properties) таблицы ресурсов (в формате json) — это поле используется для выборки TV
 б) при фильтрации и сортировках подключаются через JOIN только те TV, которые участвуют в этих фильтрах/сортировках (как правило, их не более 3 за раз, а 3 JOIN'а выполняются вполне себе быстро)
 в) в случаях, когда ресурс имеет большое количество TV, а в конечной выборке необходимо получить 2-3 TV-ки, эти TV join'ятся (так быстрее: на json-декодирование большого числа TV нужно время), в остальных случаях для выборки использую поле (properties) с последующим json-декодированием

Если речь о десятках и более тысяч документов, то 

Если вся суть проекта крутится вокруг этой галереи, то такой подход предпочтительней. УРЛы, параметры индексации, ТВ-параметры и все такое.

Если вся суть проекта крутится вокруг этой галереи

И раз уж пишу тут, всё-таки предложу. Если интересно — напишите, я выложу куда-нибудь.

Чессказать времени совсем нет что-то смотреть. Сорри.

И раз уж пишу тут, всё-таки предложу. Если интересно — напишите, я выложу куда-нибудь. Чессказать времени совсем нет что-то смотреть. Сорри.

И раз уж пишу тут, всё-таки предложу. Если интерес

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

В целом по проекту: сочувствую…

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

в) данные занимают меньше места за счёт индивидуал

Пожалейте тех, кому потом придется с такой галереей работать. 

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

Пожалейте тех, кому потом придется с такой галереей работать. Например, Василий, я уверен, выбрал бы именно такой вариант (отдельная таблица).
 А что там за проблемы возникнут при работе с такой галереей?

Пожалейте тех, кому потом придется с такой галерее

то разве это галерея? В моем понимании, в галерее создаются изображения, а тут получается, что создаются страницы. 

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

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

то разве это галерея? В моем понимании, в галерее 

В смысле, я что-то не то делаю? Или проект на modx труднореализуем?

В целом по проекту: сочувствую… В смысле, я что-то не то делаю? Или проект на modx труднореализуем?

В целом по проекту: сочувствую… В смысле, я что-то

Он просто труднореализуем:) Не важно на чем. Но не безнадежен.

Он просто труднореализуем:) Не важно на чем. Но не

Моя реплика относится к «Для каждого графического файла создаётся отдельный ресурс (типа «Документ» или «Статический ресурс») с TV-параметрами» — у Василия я кину на страницу 100 файлов и готово, а тут 100 раз «создать ресурс» — «открыть файл-браузер» — «загрузить картинку» — «выбрать картинку» — «сохранить ресурс».
 

У Василия вариант 2 получается, потому что ms2Gallery рассчитана на то, чтобы на странице ресурса вывести много картинок. И я бы тоже выбрал вариант 2, но в вашем случае получается, что отдельная страница на картинку, куча характеристик, комментарии — то есть скорость работы с картинками в ms2Gallery нивелируется скоростью заполнения характеристик для каждой картинки. То есть для пользователя будет почти одинаково, что вариант 1, что вариант 2, зато для вас быстрее будет сделать вариант 1.


Моя реплика относится к «Для каждого графического файла создаётся отдельный ресурс (типа «Документ» или «Статический ресурс») с TV-параметрами» — у Василия я кину на страницу 100 файлов и готово, а тут 100 раз «создать ресурс» — «открыть файл-браузер» — «загрузить картинку» — «выбрать картинку» — «сохранить ресурс». У Василия вариант 2 получается, потому что ms2Gallery рассчитана на то, чтобы на странице ресурса вывести много картинок. И я бы тоже выбрал вариант 2, но в вашем случае получается, что отдельная страница на картинку, куча характеристик, комментарии — то есть скорость работы с картинками в ms2Gallery нивелируется скоростью заполнения характеристик для каждой картинки. То есть для пользователя будет почти одинаково, что вариант 1, что вариант 2, зато для вас быстрее будет сделать вариант 1.

Моя реплика относится к «Для каждого графического 

а) все TV-поля дублируются в поле (properties) таблицы ресурсов (в формате json) — это поле используется для выборки TV

Есть еще вариант дублировать их в отдельную таблицу (:

а) все TV-поля дублируются в поле (properties) таблицы ресурсов (в формате json) — это поле используется для выборки TV Есть еще вариант дублировать их в отдельную таблицу (:

а) все TV-поля дублируются в поле (properties) таб

Чем сложнее проект, тем меньше потенциальных конкурентов

Чем сложнее проект, тем меньше потенциальных конку

Есть еще вариант дублировать их в отдельную таблицу (: 

Тогда для каждого типа ресурсов придётся свою таблицу создавать с TV (из-за ограничения на число индексов в одной таблице). Ну а коли для каждого типа ресурсов будет своя таблица, то и сами ресурсы логично будет хранить в этих таблицах. А коли ресурсы будут храниться в отдельных таблицах, тогда и modx не нужен.

Есть еще вариант дублировать их в отдельную таблицу (: Тогда для каждого типа ресурсов придётся свою таблицу создавать с TV (из-за ограничения на число индексов в одной таблице). Ну а коли для каждого типа ресурсов будет своя таблица, то и сами ресурсы логично будет хранить в этих таблицах. А коли ресурсы будут храниться в отдельных таблицах, тогда и modx не нужен.

Есть еще вариант дублировать их в отдельную таблиц

А еще тем выше риски, издержки и т.п., и соответственно ниже профит и больше срок окупаемости. Тут не все так однозначно.

А еще тем выше риски, издержки и т.п., и соответст

В своём проекте я не использую какие-либо сторонние сниппеты и компоненты (кроме компонентов для работы с комментариями), поскольку ни один компонентов не обеспечивает требуемого функционала проекта. Даже элементарно хлебные крошки, пагинация, баннеры, псевдонимы, uri, ajax-подгрузка, редиректы, SEO и многое другое — всё это реализовано собственным кодом с индивидуальной логикой. Соответственно, и сабжевый вопрос подразумевает написание собственного интерфейса для загрузки изображений (но только для загрузки). Именно поэтому, я и не рассматриваю здесь возможность использования сторонних компонентов в качестве критерия выбора. Ну а собственный интерфейс для загрузки изображений будет обеспечивать возможность загрузки и одного изображения, и нескольких одновременно (с указанием характеристик для каждой из них).


В своём проекте я не использую какие-либо сторонни

У Василия вариант 2 получается, потому что ms2Gallery рассчитана на то, чтобы на странице ресурса вывести много картинок.

И в вариантах 1 тоже просто вывести много картинок на странице. Только браться они будут не из одной папки на диске (соответствующей одному ресурсу), а из нескольких (зависит от физической организации папок с изображениями) — т.е. делаем выборку требуемых ресурсов-изображений по их TV-характеристикам и получаем url'ы физических файлов.
 

В случае с ms2Gallery — там ведь нет характеристик у каждого изображения? И связь изображений с ресурсами М:1, а у меня — М: М

У Василия вариант 2 получается, потому что ms2Gallery рассчитана на то, чтобы на странице ресурса вывести много картинок. И в вариантах 1 тоже просто вывести много картинок на странице. Только браться они будут не из одной папки на диске (соответствующей одному ресурсу), а из нескольких (зависит от физической организации папок с изображениями) — т.е. делаем выборку требуемых ресурсов-изображений по их TV-характеристикам и получаем url'ы физических файлов. В случае с ms2Gallery — там ведь нет характеристик у каждого изображения? И связь изображений с ресурсами М:1, а у меня — М: М

У Василия вариант 2 получается, потому что ms2Gall

> Если речь о десятках и более тысяч документов, то это поможет: habrahabr.ru/post/253737/
 > Но этот вариант не всегда реализуем. Как, например, в моём случае.
 > В целом по проекту: сочувствую… 

Некоторые TV всё-таки пришлось разместить в таблице ресурсов. А именно — числовые поля. И только те числовые, по которым выполняется фильтрация (на больше/меньше) и сортировка. Т.к.:
 а) во всех остальных случаях фильтрация и сортировка вполне себе нормально отработает и по строковым TV (с использованием индекса)
 б) с числовыми TV-полями при выполнении сортировки и фильтрации (на больше/меньше) пришлось бы выполнять преобразование на лету и как следствие, полный перебор БЕЗ использования индексов
 в) в нашем распоряжении имеется всего 44 индекса (64 минус 20 стандартных), соответственно, все TV в таблицу ресурсов не закинешь. Закидываю только необходимый минимум (числовая сортировка/фильтрация)
 

Но логику, описанную в статье, немного изменил (под свой проект):
 1.Числовые TV не перемещаю в таблицу ресурсов, а копирую. Памяти уходит больше, но упрощается логика + повышается безопасность (если что «поломается», всегда можно восстановить значения из стандартных TV)
 2.Схему (modx->map) дополняю новыми полями также на лету, но не вручную, а программно — на основе структуры таблицы в БД (использую генератор xPDOGenerator)
 3.Описание индексов новых полей в (modx->map) не помещаю, т.к. индексы xpdo нужны только для генерации таблиц в БД (или нужны для чего-то ещё ?)
 

 — Таким образом, получилась гибридная система TV-параметров:
 1.Для выборки TV используется поле (properties)
 2.Для фильтрации и сортировки по числовым полям используются собственные поля в таблице ресурсов (числовое сравнение)
 3.Для фильтрации и сортировки по строковым полям — TV-поля подключаются через join (строковое сравнение)
 

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

> Если речь о десятках и более тысяч документов, то это поможет: habrahabr.ru/post/253737/
 > Но этот вариант не всегда реализуем. Как, например, в моём случае.
 > В целом по проекту: сочувствую… Некоторые TV всё-таки пришлось разместить в таблице ресурсов. А именно — числовые поля. И только те числовые, по которым выполняется фильтрация (на больше/меньше) и сортировка. Т.к.:
 а) во всех остальных случаях фильтрация и сортировка вполне себе нормально отработает и по строковым TV (с использованием индекса)
 б) с числовыми TV-полями при выполнении сортировки и фильтрации (на больше/меньше) пришлось бы выполнять преобразование на лету и как следствие, полный перебор БЕЗ использования индексов
 в) в нашем распоряжении имеется всего 44 индекса (64 минус 20 стандартных), соответственно, все TV в таблицу ресурсов не закинешь. Закидываю только необходимый минимум (числовая сортировка/фильтрация) Но логику, описанную в статье, немного изменил (под свой проект):
 1.Числовые TV не перемещаю в таблицу ресурсов, а копирую. Памяти уходит больше, но упрощается логика + повышается безопасность (если что «поломается», всегда можно восстановить значения из стандартных TV)
 2.Схему (modx->map) дополняю новыми полями также на лету, но не вручную, а программно — на основе структуры таблицы в БД (использую генератор xPDOGenerator)
 3.Описание индексов новых полей в (modx->map) не помещаю, т.к. индексы xpdo нужны только для генерации таблиц в БД (или нужны для чего-то ещё ?) — Таким образом, получилась гибридная система TV-параметров:
 1.Для выборки TV используется поле (properties)
 2.Для фильтрации и сортировки по числовым полям используются собственные поля в таблице ресурсов (числовое сравнение)
 3.Для фильтрации и сортировки по строковым полям — TV-поля подключаются через join (строковое сравнение) При такой организации TV:
 а) и выборку большого числа TV можно будет сделать довольно быстро (без кучи JOIN'ов)
 б) можно быстро (с использованием индекса) выполнять фильтрацию и сортировку как по строковым полям (строковое сравнение), так и по числовым полям (числовое сравнение), исключая преобразование типов на лету
 в) можно не заморачиваться тем, что в таблице ресурсов остаётся всего 44 индекса для собственных полей (для числовых полей, по которым выполняется фильтрация/сортировка, их всем хватит)

> Если речь о десятках и более тысяч документов, т

И здесь как всегда проблема с индексами возникает. Если, например, в таблице ресурсов мы создаём числовое поле (sCount) и индекс idx_sCount по этому полю, то при выполнении запросов, в которых выполняется фильтрация и по полю published (или deleted), и по числовому полю (sCount) (не важно, в какой последовательности), то MySQL будет использовать индекс published, а не idx_sCount (как этого следовало бы ожидать) — это приведёт к почти полному перебору всех ресурсов (если положить, что почти все ресурсы являются опубликованными). Аналогично и с (deleted).
 При этом если в таблице будет индекс по обоим этим полям, то MySQL выберет именно этот индекс (как и должно быть).
 

Решить проблему можно 3 способами:
 1.Для каждого запроса указывать необходимый индекс. Сложности этого способа очевидны:
  — сложна реализация (xpdo индексы не поддерживает)
  — необходимый индекс придётся указывать для каждого запроса и при изменении имени или структуры индекса придётся все эти запросы пересматривать
 

2.Для собственных полей указывать составные индексы, начинающиеся со стандартных полей и заканчивающиеся собственными полями (например: idx_published_sCount, idx_classKey_deleted_published_sCount). Но в этом случае часть существующих запросов может начать тормозить, поскольку при наличии 2, 3 и более индексов, начинающихся со стандартных полей, MySQL на некоторых запросах (предположительно, с конструкцией IN + может зависеть и от версии MySql) начинает очень долго выбирать оптимальный индекс: modxclub.ru/topics/vyiborka-iz-%28modtemplatevarresource%29-sushhestvennoe-uskorenie-pri-yavnom-ukazanii-indeksa-1759.html#comment-7177
 

3.Для собственных полей указывать составные индексы, начинающиеся с собственных полей и заканчивающиеся стандартными (например: idx_sCount_published, idx_sCount_classKey_deleted_published). В этом случае эти индексы MySQL будет рассматривать в качестве возможных только в тех запросах, в которых используются наши собственные поля. И при этом в тех запросах, в которых присутствуют условия и по стандартным полям, и по нашим полям, будет использовать именно эти (наши) составные индексы, а не простые стандартные.

И здесь как всегда проблема с индексами возникает. Если, например, в таблице ресурсов мы создаём числовое поле (sCount) и индекс idx_sCount по этому полю, то при выполнении запросов, в которых выполняется фильтрация и по полю published (или deleted), и по числовому полю (sCount) (не важно, в какой последовательности), то MySQL будет использовать индекс published, а не idx_sCount (как этого следовало бы ожидать) — это приведёт к почти полному перебору всех ресурсов (если положить, что почти все ресурсы являются опубликованными). Аналогично и с (deleted).
 При этом если в таблице будет индекс по обоим этим полям, то MySQL выберет именно этот индекс (как и должно быть). Решить проблему можно 3 способами:
 1.Для каждого запроса указывать необходимый индекс. Сложности этого способа очевидны:
  — сложна реализация (xpdo индексы не поддерживает)
  — необходимый индекс придётся указывать для каждого запроса и при изменении имени или структуры индекса придётся все эти запросы пересматривать 2.Для собственных полей указывать составные индексы, начинающиеся со стандартных полей и заканчивающиеся собственными полями (например: idx_published_sCount, idx_classKey_deleted_published_sCount). Но в этом случае часть существующих запросов может начать тормозить, поскольку при наличии 2, 3 и более индексов, начинающихся со стандартных полей, MySQL на некоторых запросах (предположительно, с конструкцией IN + может зависеть и от версии MySql) начинает очень долго выбирать оптимальный индекс: modxclub.ru/topics/vyiborka-iz-%28modtemplatevarresource%29-sushhestvennoe-uskorenie-pri-yavnom-ukazanii-indeksa-1759.html#comment-7177 3.Для собственных полей указывать составные индексы, начинающиеся с собственных полей и заканчивающиеся стандартными (например: idx_sCount_published, idx_sCount_classKey_deleted_published). В этом случае эти индексы MySQL будет рассматривать в качестве возможных только в тех запросах, в которых используются наши собственные поля. И при этом в тех запросах, в которых присутствуют условия и по стандартным полям, и по нашим полям, будет использовать именно эти (наши) составные индексы, а не простые стандартные.

И здесь как всегда проблема с индексами возникает.

3.Описание индексов новых полей в (modx->map) не помещаю, т.к. индексы xpdo нужны только для генерации таблиц в БД (или нужны для чего-то ещё ?)

Нужны только для генерации. Но если вдруг будете потом на основе мапы таблицу создавать, то конечно же они понадобятся.
 

3.Описание индексов новых полей в (modx->map) не помещаю, т.к. индексы xpdo нужны только для генерации таблиц в БД (или нужны для чего-то ещё ?) Нужны только для генерации. Но если вдруг будете потом на основе мапы таблицу создавать, то конечно же они понадобятся.

3.Описание индексов новых полей в (modx->map) не п

галерея

изображения

способ хранения

характеристики

характеристики изображений

хранение характеристик изображений

# Николай Ланец aka Fi1osof
**Lead Fullstack Developer / Ментор / Евангелист современного JS‑стека**

---

## О себе

Я — не просто Senior Developer с 2007 года. Я — тот, кто строит продукты будущего на базе современных технологий и помогает другим подниматься на новую ступень айти-карьеры. Создатель и идейный вдохновитель freecode.academy — платформы, где обучение перестает быть скучной обязаловкой и становится настоящим технологическим приключением.

---

## Мой стек и философия разработки

Основу моего рабочего арсенала составляют:

- [Javascript](/technologies/ck1faudv928l40a89c4u9zxlm), [TypeScript](/technologies/ckcvwwx010kov08009u7y2rav)
- [React](/technologies/ck1fawbdw28v20a891k4wlh27), [Next.js](/technologies/ckg2jd4ffr9260730aog66dri)
- [Node.js](/technologies/ckt55wm59272831wo9gg9r8ynx), [GraphQL](/technologies/ck1fawhqk28vu0a8995lqvlsj), [Apollo Client](/technologies/ck2zdcg0vpvc10a89xjmhj1e0), [Nexus](/technologies/ckl2pbh0fxew60730ifl3zozp), [Prisma](/technologies/ck2zdbmi7pv8r0a89ntc2r0f1)
- DevOps: [Docker](/technologies/ck2y1x9lho9cy0a8953xzfjr8), [docker-compose](/technologies/ck2y1xqino9g80a89tsftxin2), [Caddy](/technologies/ck2zd8ovqpuyl0a8909748sbu), [Ubuntu](/technologies/cktu8giks3593911vmle30ztqxt)
- UI-инструменты: [Styled-Components](/technologies/ckk8myysio7lw0730csszvrdw), [Material-UI](/technologies/ckljv3jwd7bgf0730huxlko9n), [react-hook-form](/technologies/ckmx8cn9fmwrv073032e67722)
- Всё актуальное для разработки, CI/CD и автоматизации 
- Эксперименты с [WebGL](/technologies/ckan9anntc12f08003saqttrq), [A‑Frame](/technologies/ck2tgoiz8j37y0a89c7gxsrxc), [Three.js](/technologies/ck2tgns1nj32z0a89vmw7xw3f), [Unreal Engine 4](/technologies/ck7puswy6g4yb07004cdp6lbr), [Elixir](/technologies/ckn0olavrnnzi0730xs8rctn8), [C++](/technologies/cknin1y8lu2fr07307mskn2fn)

---

## Разработка и менторство

- Более 15 лет **hands-on** разработки и проджект‑менеджмента
- Главный разработчик и преподаватель платформы [freecode.academy](https://freecode.academy)
- **Ведущий менти-пул на платформе** — лично выращиваю новых звезд отрасли

### Мои менти и их результаты

| Менти (ФИО \| username)                               | Уровень | Рейтинг |
|-------------------------------------------------------|---------|---------|
| [Попов Дмитрий \| linklib](/users/cjoe890c706ji0d962oismzoe)           | 3       | 315     |
| [Сэт \| defk1lla](/users/ckzh1ita312978121imr9hpqfc64)                 | 3       | 670     |
| [Ксения Матвеева \| Ксения Матвеева](/users/ckz4awwlh10627771imr4wvpb7cj) | 2       | 0       |
| [Михаил \| Balamut](/users/cl1npq92z10258261vmbq0w6vfh2)               | 2       | 0       |
| [Ольга Ершова \| angel](/users/cjoe87zhk00250d969arluevk)              | 1       | 0       |
| [Егор \| rogedkone](/users/cksrdp47d3308261ijuq7wfrxdl)                | 3       | 0       |
| [Roman \| Roman43](/users/ckur2qtt64721431xoboyjcte52)                 | 2       | 0       |
| [Бут Игорь \| santiment](/users/ckttd9x20893951vmltb8t7sha)            | 1       | 0       |

**Доношу простую мысль: успех — это не магия, это осознанная системная работа и кайф от роста.**
Мои менти выводят решения в продакшн, пробиваются в лидеры рейтингов — кому не хочется быть в такой команде?

---

## Почему я?

- **Прокачаю проект** — от TDD архитектуры до культурного CI/CD
- **Вдохновлю команду** — и научу мыслить по‑новому, где ИИ — напарник, а не угроза
- **Выращу мидлов и сеньоров** — доказано платформой и рейтингами моих учеников

**Сила — в сообществе, а техника — это просто смазка для ваших побед. Присоединяйтесь!**

---

## Контакты

- 📧 [n.lanets@freecode.academy](mailto:n.lanets@freecode.academy)
- Телеграм: [@freecode_academy](https://t.me/freecode_academy)

---

**P.S.**: Мой опыт — ваш драйвер роста. Хотите в команду? Ищете менторство? Пишите. Растём вместе!