• Так как недавно прочитал на этом форуме, что кастомные поля в посту не индексируются (по этому их выборка проходит гараздо медленнее), решил большую часть данных перевести в таксономии (если бы тут можно было вылаживать фаги, я бы написал небольшую статью, так как из интернетов понял что многие не понимают зачем как и где применять таксономии, а в других случая дополнительные поля, так как при детальном изучении, в принципе стало понятно зачем и для чего эти два варианта придумали в WordPress).

    Пару вопросов, по поводу поля цена.

    Так как будет реализован поиск по ценам, а цены собственно самые разные, то, таксономии, для этого варианта не подходят. Остаётся два варианта.

    1. Кастомные поля — на сколько будет быстрый поиск если постов будет много ? Но, кастомных полей в ключая цену, будет всего пару тройку штук ?
    2. Создание собственной таблицы с индексом — вопрос, как её можно интегрировать в WordPress чтобы потом с ней работать ?

Просмотр 11 ответов — с 1 по 11 (всего 11)
  • Проще индекс на meta value добавить

    Читал, писали что при большом количестве — это типа ноусенс, по этому его там нет изначально.

    Как вариант, предлагали сделать отдельную таблицу и встроить её в работу wp.

    Смотрите, про отдельную таблицу… как только вы ее заводите, вам придется создавать решения ускорения выборки данных, которые находятся под капотом WP_Query и о которых мы не знаем. Навскидку могу предложить несколько вариантов бестабличного решения, в порядке усложнения реализации:

    1. использовать для фильтрации цены терм ее диапазона.
    2. Сделать кастомную таксономию «цена»… или две, одну для рублей, вторую для копеек, с перечислением значений.
    3. впилить в таблицу wp_posts еще одно поле (с индексацией)
    4. сделать на хуках и фильтрах предварительную выборку постов в базе с помощью VIEW, а сортировку уже в результатах обращения к.

    Любой из этих способов привинчивания к велосипеду многоугольных колес доставит вам не меньше удовольствий, чем создание собственной таблицы (реализованной уже в woocommerce), а тормозить будет на порядок меньше, чем собственная таблица.

    И да, кастомных полей под капотом wordpress значительно больше, чем пара-тройка штук (загляните в базу).

    Причём тут woo, я посмотрел как они сделали таксы, стало понятно, как они используют термы, в принципе это должно было быть понятно и без того, просто у них уже готовый пример на продукции.

    На счёт таблицы, думаю быстрей чем своя собственная уже не придумаешь. Термы я ещё не понял как можно использовать для цен, потому что там нет нужно оператора при их выборке, к примеру он есть в мета дополнительных полях. К примеру я могу в мета найти цены с 10,50 по 11,80, а вот с термами такое сделать думаю будет очень затруднительно. Тем более если в постах будет всего пара тройка штук доп.полей к примеру цена, размеры и пару статических данных то нагрузка на выборку из них будет намного меньше если бы там были всё поля которых в раза три-четыре больше.

    woo тут при том, что у них собственные таблицы. в которых, к примеру, цена имеет отдельное поле, а то и два (минимальная… максимальная). соответственно нет проблем с индексацией, как в помойке postmeta. но авторам плагина пришлось фактически переписать выборку данных движка под себя.

    К примеру я могу в мета найти цены с 10,50 по 11,80, а вот с термами такое сделать думаю будет очень затруднительно.

    Да легко.

    вариант 1. делаете таксономию, содержащую 100 границ диапазонов от 0 до 99 и вторую, содержащую 100 границ диапазонов от 0 до 0,99. назначение термов происходит автоматически при сохранении в админке поля с ценой. дальше немного логики в запросах.

    вариант 2. задаете более грубые диапазоны цены. например, от 10 до 12… точность в копейки реальным пользователям не нужна. думаю даже, что вилок 1-10, 11-100, 101-1000 будет достаточно (а это уже всего три терма, вычисляемых при сохранении в админке цены товара), во всяком случае многие серьезные магазины с такими вилками работают активно

    @efess переписывать конечно я ничего не буду, я имею ввиду стандартный функционал wp, но, считаю что в этом случае легче сделать свою таблицу, с ценами и индексом, чем придумывать с термами какой-то ценовой-конструктор. В теории на выборку с вариантом (своя таблица) нужно будет сделать, всего-то 2 запроса, причем все они с индексом, как в собственной таблице так и в таблице wp. Куда ещё проще я не знаю. В любом случае считаю это лучше чем вариант с термами, красивее и проще. Посмотрим как реализую. Но, за термы, спасибо, что упомянули, я просто не знаю как я упустил это при разработке, наверно потому что я думал что используются только кастомные поля и всё, для этого дела.

     Куда ещё проще я не знаю. 

    Проще, пожалуй, будет добавлять по pre_get_posts в sql запрос через фильтры вашу таблицу. Тогда дополнительные запросы не понадобятся.

    Интересно, если оставить в цены в метах, то сколько нужно контента, чтобы такой поиск начал нагружать БД… на среднем VPS.. (если поиск по доп.полям) в каждом посте не более 3-4 штук включая цену.

    По опыту, начиная с базы в 1гб, при посещаемости от 10к просмотров в сутки, появляются медленные запросы по постмета. Это только ориентир, потому что сильно зависит от возможностей кэша.

    • Ответ изменён 1 месяц, 2 недели назад пользователем efess.

    Спасибо за инфу, думаю тогда будет достаточно времени, в случае чего. Интересно сколько там было постов в такой базе

Просмотр 11 ответов — с 1 по 11 (всего 11)

Для ответа на тему необходимо авторизоваться.