Игорь Яцевич

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

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

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

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

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

и т.д.

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

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

# все, кроме определенных
  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