Как в Eloquent (или ActiveRecord) получить всех потомков n-ного уровня, в таблице с полями id и parent_id? Нужны ли воспомогательные таблицы?

Question

[Роми]

Есть таблица с полями id и parent_id - как наименее ресурсозатратно получить всех потомков n-ного уровня, используя ларавелевский Eloquent?

Это вообще реально, или нужно raw-запросы писать на SQL?

Годится ли MySQL 5.7 или нужен непременно 8-й? Я вроде слышал что там что-то новое появилось для иерархических деревьев. Или может вообще какой-нибудь Postgre взять?

Насколько вообще реально это реализовать только в одной таблице? Ибо я полагаю, что если записей будет over 1M, и нужно будет получить потомков глубже 3 уровня - то там начнется какой-нибудь кошмар, да?

В общем, если кто знаком с этой темой по личному опыту - буду рад совету.

Спасибо.

Comments

[Akina]

Есть таблица с полями id и parent_id - как наименее ресурсозатратно получить всех потомков n-ного уровня

Определите, какой (или какие) именно ресурс хочется сэкономить?

Годится ли MySQL 5.7 или нужен непременно 8-й?

Годится. Правда, это будет не SELECT, а CALL.

Насколько вообще реально это реализовать только в одной таблице? ... нужно будет получить потомков глубже 3 уровня

Если это основная задача - настоятельно советую пересмотреть структуру хранения.

[Роми]

Akina,

Если это основная задача - настоятельно советую пересмотреть структуру хранения.

Пересмотреть каким именно образом? Делать на графовой БД - морально не готов)) скажу сразу))) Будь сроки побольше - мб и рассмотрел бы))

Да, построение иерархических деревьев - основная задача для данного модуля. Что посоветуете?

[Роми]

Akina,

Определите, какой (или какие) именно ресурс хочется сэкономить?

Ну просто чтобы это было подъемно для обычного VPS с 4 Гб оперативки или типа того.

[Akina]

Роми,

Пересмотреть каким именно образом?

Уйти с parent-child на более предназначенную для описанной задачи структуру.

Если основная задача - именно построить дерево, то можно посмотреть в сторону хранения нод в виде FQPath.

Answer 1

[Григорий Васильков]

Нужны ли воспомогательные таблицы?

Да, желательно.

Это вообще реально, или нужно raw-запросы писать на SQL?

Чтобы было еще быстрее - да. А без дополнительной таблицы - тем более да.
Вот как делать: https://www.percona.com/blog/2011/02/14/moving-sub...

Ибо я полагаю, что если записей будет over 1M

Индексы решат проблему с миллионом. А еще проблему миллиона решает взгляд на то, что если ты решил "вывести на страницу миллион" - то ты что-то не так обсудил с заказчиком. Человеку от 20 записей уже становится голове тяжело, а лям - это забей.

Есть паттерн Closure Table (я рекомендую его), есть паттерн Nested Sets (для меня тяжелый в чтении, и средний в реализации) и есть паттерн Path Enumeration (самый простой при реализации, и без дополнительной таблицы, но в итоге может не всё) и опирается на WHERE LIKE %path/to/parent%.

Все они реализуют дерево в таблице, позволяя избежать необходимости поддержки рекурсивных запросов, которая в MySQL есть только в более поздних версиях и есть в постгресе. Но честно, я когда разбирался в WITH RECURSIVE понял что с паттернами легче было.

Comments

[Роми]

Индексы решат проблему с миллионом. А еще проблему миллиона решает взгляд на то, что если ты решил "вывести на страницу миллион" - то ты что-то не так обсудил с заказчиком. Человеку от 20 записей уже становится голове тяжело, а лям - это забей.

Слушай, а ведь точно! Если индекс на парент_ид - ему же не придется всю таблицу шерстить!)) Я как-то сразу не подумал, спасибо! )) Остальное непременно изучу паттерны эти. Если честно - хотел да использовать новые фичи из MySQL 8, там что-то как раз насчет деревьев, но... в общем, посмотрим )))