Продумать структуру базы. категории 3-го или 4-го уровня вложенности

Один запрос.

а как одним?

Джойнить жеж.

lutskboy, это называется списком смежных вершин (adjacency list).

Пример с двумя уровнями и разными таблицами я описал в статье Как сделать фильтрацию элементов по уровню иерархии? В общем же вы должны присоединять таблицу к самой себе под разными алиасами по совпадению parent.id с parentid.

---------- Добавлено 21.09.2018 в 00:28 ----------

P.S. Запросы в чистом виде можно в демке к статье посмотреть.

P.P.S. В показанном у меня коде в финальный запрос могут вставляться фактические данные в качестве значений выбираемых полей. Это связано с тем, что движок их получает автоматом отдельными запросами, делая «прямой» обход адреса при его обработке. Вам это делать не обязательно.

Есть разные способы хранения дерева в базе, кроме уже упомянутого adjacency list еще есть nested sets и materialized path - погуглите статьи про эти термины и выберите что вам больше по душе.

Сам пользовался nested sets - там много что можно выбрать в один запрос, но вот вставка и обновление нетривиальны, да.

Ну вы блин даёте... adjacency list, nested sets, materialized path... Пошто людей пугаете? 🤪

Sitealert, ну лично я дал ТСу ключ для дальнейшего поиска инфы о том, про что он спрашивал.

---------- Добавлено 21.09.2018 в 19:39 ----------

Кстати, по-моему nested sets на слуху дальше больше, чем первое, несмотря на простоту и популярность первого подхода.

---------- Добавлено 21.09.2018 в 20:06 ----------

Для «стабильной» структуры каталога nested sets тоже сойдет, иначе при обновлении нужно перелопачивать в среднем половину вершин. Но можно отделить конечные элементы от структуры каталога.

Элементы «материализованного пути» можно использовать в том числе и в списке смежных вершин для контроля уровня вложенности, валидации путей, возможности использовать одинаковые слаги в разных вершинах и т.п. Например, в упомянутом мной выше движке к узлу первого уровня (catalogs) можно привязать таблицу списка смежных вершин, содержащую вместо слагов такие элементы:

CARS_FOREIGN

CARS_FOREIGN/DAEWOO

и т.п. Конечные элементы, например товары, я обычно храню в отдельной таблице.

Если есть поле parentid, где хранится category_id родителя, то можно хоть 100 уровней вложения делать и вытаскивать все категории из базы всё равно одним запросом, даже без джоинов (ну тут зависит от того, есть ли все необходимые данные в одной таблице). Дальше в дело вступает ваш язык программирования. Тут полученный из БД объект/массив нужно будет использовать для создания нового массива, где у каждого объекта категории будет вложенный объект (если есть подкатегории), содержащий все подкатегории. Ну это одно из решений, которое можно слепить на коленке, и оно будет работать. По крайней мере в старых версиях Simpla CMS делалось именно так.

Ерунду не пишите. Никто все данные в одной таблице не хранит. У элементов и у категорий совершенно разные данные. Так же как и у разных категорий совершенно необязательно одинаковая структура данных. Даже если все записи хранить в одной таблице, то понадобятся вспомогательные таблицы со всякими полями и опциями.

pringlesday, пример запроса «без джоинов» в студию. И структуру таблицы заодно, если она отличается от представленной ТСом.

---------- Добавлено 25.09.2018 в 14:19 ----------

P.S. ТС походу подзабил на тему. Видать, конкретно загрузили :) Или сидит втихаря кодит :D