Говорят TV-полями просто лучше не злоупотреблять, в плане производительности
Это тоже стало мемом, как и «MODX умирает». «TV - это плохо». Причем смешно-то как, её и когда-то очень хвалили, удобно, создал TV, привязал к шаблону и погнали.
TV прекрасный инструмент и не надо его бояться использовать. Минусы есть и их не много:
1. Скорость работы с ними при выборке. Но это тоже довольно спорно, я понимаю что много JOIN-ов происходит при выборке, но вот попался мне проект на оптимизацию с 33К ресурсами. Разработчик "одаренный", использовал Minishop2 и TV, вместо опций, порядка 10-ти TV в которых хранились числовые данные. Так вот, хоть и мне пришлось расширить таблицу и перенести данные туда, я бы не сказал что сайт тормозил.
Вдруг кто не знает, почему несколько JOIN-ов нужно для получения TV, для того чтобы TV были такими удобными, есть 3 таблицы:
modx_site_tmplvars - храняться основные данные о TV (ID, Название, Описание,...)
modx_site_tmplvar_templates - храниться пара ID TV и ID шаблона, т.е. какой TV к каким шаблонам относиться
modx_site_tmplvar_contentvalues - данные TV, т.е. ID TV, ID ресурса и значение
Это удобно для расширения, но затратно в больших проектах, ведь если посмотреть структуру данных, то выясниться, что в modx_site_tmplvar_contentvalues у нас только ID TV и значение. Т.е. одним JOIN-ом не обойтись, ведь важные данные еще и в таблице modx_site_tmplvars, такие как: Название, Параметры вывода, Значение по умолчанию.
2. Тип данных. Если коротко, то все TV в бд храняться как текст, нет, это не разработчики тупые, а это просто жертва в пользу универсальности.
Итог, ребята, не бойтесь и пользуйтесь TV до тех пор пока у вас не будет проект с 10К+ товарами с 5-10+ характеристиками, с выводом на фронте всех товаров (или много) без пагинации, со сложной фильтрацией и с потоком клиентов 10К+ в сутки.