Можно и мантикору, но я порекормендую все-таки эластик. Это примерно как Жигули и Фольксваген. Ездить будет, но хуже, а главное - при переезде в Европу твои навыки замены карбюратора не пригодятся.
В любом случае, с внешним поисковым движком искать уже будет он сам, а этот запрос вообще не понадобится.
Судя по нелепости тех фрагментов кода, которые мы видим, автор просто-напросто вызывает функцию mysqli_query только один раз. Какой запрос успевает в нее попасть - то и исполняется.
Мысль о том, эту функцию можно вызвать два раза, видимо ещё пока слишком сложна для понимания.
mayton2019, судя по всему, вы не понимаете, что такое теги.
Вот смотрите, на этом сайте используются теги: mysql, php - и так далее.
Для их поиска нужно только имя. Им не нужен никакой "Стемминг", "Лемматизация" и убирание предлогов. И всё остальное, что вы тут нафантазировали.
Ваша идея давно понятна. И я уже писал выше, что она собой представляет.
Такие гении, предлагающие "оставить нормализацию за кадром" и "слить все в JSON", тут стадами бегают. А спроси его потом - а как тег из системы удалить, или переименовать, или слить два тега в один - только глазками хлопают.
mayton2019, я с трудом понимаю ваш язык. Поэтому опишу то, как я вас понял, и попробую объяснить, как это работает на самом деле. Если вы что-то другое имели в виду, то поправьте.
Что такое "теги == токены" я не понял совсем.
"текстовый поиск" - это, как я понимаю, полнотекстовый поиск.
Он здесь не нужен, поскольку у нас нет текста. А есть простая таблица, где поиск происходит просто по совпадению. По колонке с именами тегов строится обычный индекс, и нужные строки находятся мгновенно. Затем через джойн, по первичному ключу, точно так же мгновенно находятся нужные посты, привязанные к найденным тегам.
Это самые основы реляционной архитектуры.
Сначала сливать нормализованные данные в одну колонку, а потом строить по ним полнотекстовый индекс - это по осмысленности примерно как отрезать себе уши и пришить их к нижней части спины, соединив с головой звукопроводящими трубками от стетоскопа. Работать будет, но криво, а главное - непонятно зачем.
mayton2019, ну вот зачем советовать глупости? А потом как редактировать привязанные теги? переименовывать? Объединять? Ну это же первый класс, начальная школа баз данных. У человека сделано все нормально, а вы его обратно в пещеру тянете. Только потому что не знаете, как простейший запрос составить
Дмитрий, ваша беда в том, что вы общаетесь с какими-то фантазиями в своей голове. При том что вы комментируете вообще-то конкретный вопрос. В котором ни "скорости отдачи", ни "двух гигабайт" нет и в помине. Даже если вы про них что-то "знаете", к вопросу это всё не имеет никакого отношения.
Дмитрий, послушайте, сначала вы выдумали себе какую-то скорость загрузки. Теперь вы придумали какие-то "два гигабайта", чтобы оправдать эту выдуманную скорость загрузки. Может, стоит остановиться, а? Ну или применять богатую фантазию по назначению - сценарии для сериалов писать например.
Для приведенного в вопросе запроса я бы сказал что индекс по pubication бессмысленный, если бы поиск был не по этой колбасе с полным урлом. В целом этот запрос - какая-то глупость.
Откуда вообще берется эта метка времени, и зачем она в запросе? почему поиск идет по полному урлу, а не по id? Вот это, которое болтается в конце - n96349 - это же id.
