Игорь Яцевич

На еластике это решается так https://project-a.github.io/on-site-search-design-...

на mysql - тоже можно, через запросы с фильтрацией по выбранным значениям в форме и группировкой по атрибутам всех имеющихся значений для товаров. Тут с ростом данных будет проседать время ответа, но это надо оценивать исходя из кол-ва данных на проекте, по которым идет поиск.

Проектировать схему хранения данных следует исходя из кейсов их дальнейшего использования, объема и скорости добавления данных.

Например, я бы задался след вопросами:
1. После того как я положил в базу товары что мне с ними надо будет делать?
Если просто показать названия заказанных товаров в странице админки, то достаточно будет денормализованной формы хранения.
Если же на основании данных, которые содержит в себе заказ хочется строить динамическую аналитику - например, в админке товаров простым запросом показывать сколько раз этот товар покупали, либо что то в этом духе - то будет удобнее нормальная форма. Ну либо обновлять какой то счетчик заказа у товара, тогда нормальная форма не нужна.

2. Сколько строк в заказе будет в среднем? если очень много позиций в заказе - например по 1000 и заказов много - то очень скоро объем данных в таблице с элементами заказа будет большой, и выборка по нему будет деградировать. Если данных очень много - то лучше будет денормализованная форма. Если данных мало - то наоборот.

и т.д.

И я бы лучше использовал в базе для хранения списка ID не строку с разделителями, а JSON - поле такого типа есть в Postgres, с Mysql давно не работал - но кажется тоже есть. Либо тупо в текстовое сохранять json. Если такой тип данных поддерживает база, на него можно даже строить индексы. Либо если есть, то можно рассмотреть тип данных Array если поддерживает БД.

p.s. Реляционная база данных не обязывает хранить все только в нормальной форме - ее мощь как раз в том, что можно хранить и в нормализованной форме и в денормализованной.

Ajax + HTML5 History API
History API - для того чтобы урл мог меняться в браузере, без перезагрузки страницы. Данные же грузятся с помощью ajax

Мне кажется проблема здесь в использовании переменных @first_start_time, @second_start_time . Если в запросе используются переменные, то его результаты не кешируются на уровне MySQL. Если во вложенном запросе нет никаких условий, связывающих его с внешним запросом, то результат его выполнения кешируется, иначе вычисляется для каждой строки заново.

Ну и почти любой подзапрос можно переписать в виде JOIN, только даст ли это выигрыш по производительности. Ибо мне кажется затык в переменных.

Подзапрос можно убрать так

from
 ...
 join Event as FirstEvent
   on FirstEvent.place_id = g.place_id

 where
 ..
 and FirstEvent.event_id = @first_event

# все, кроме определенных
  select
    id_first_msg,
    id_topic,
    num_views,
    0 as priority
  
  from
    smf_topics 
  
  where
    id_topic not in (1,2,3,4)
  
  # те, которые должны быть всегда включены  
  union
  select
    id_first_msg,
    id_topic,
    num_views,
    1 as priority 
  
  from
    smf_topics 
  
  where
    id_topic in (5,6,7,8,9)
  
  order by 
    priority desc,
    num_views desc 
  
  limit 50

Кто такие "соседи"? Записи с таким же значением поля "id_param"? Тогда как то так:

select
  NeighbourData.*

from
  Data as NeighbourData
  join Data as NodeData
    on NeighbourData.id_param = NodeData.id_param

where
  NodeData.id_item = 1100

Решать такие задачи надо использую планировщик очереди.
Создаешь задания сделать то и то, и бросаешь их в очередь.
А там уже может быть N воркеров, которые обрабатывают эту очередь.
Таким образом есть возможность сделать нагрузку на сервер не лавинообразной, а равномерной.

В зависимости от важности задачам можно давать разные приоритеты, и т.д.