Рекурсия

fixxxer

К.О.
Партнер клуба
Кстати, падить нулями не нужно, точка-разделитель прекрасно работает.
паддинг тут еще и для сортировки, с точками так просто не получится order by же?
а вообще идея в varbinary и pack(), строками для читаемости написал
 

mihail.zagoskin

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

fixxxer

К.О.
Партнер клуба

WMix

герр M:)ller
Партнер клуба
По дефолту будет так, как я и думал
чаще всего это не важно, достаточно pid, сортировка будет у клиента и там дата создания и имя в алфавитном порядке и другое, важнее инструмент поиска близкий к [n] иметь
 

fixxxer

К.О.
Партнер клуба
чаще всего это не важно, достаточно pid, сортировка будет у клиента и там дата создания и имя в алфавитном порядке и другое, важнее инструмент поиска близкий к [n] иметь
мы тут вроде конкретную задачу решаем а не абстрактную =)
 

grigori

( ͡° ͜ʖ ͡°)
Команда форума
facepalm .... какие нах varbinary?

про json в mysql не слышали? RTFM, старперы! там давно уже индексы по полям есть
здесь, блин, тупой направленый граф в MLM, это не rocket science - тупо храним список прямых дочек узла в json, список родителей - materialized path, и тупо выбираем узел
JSON_SEARCH(`parents`,'all',:рartent_id) AND JSON_LENGTH(дочки)<4
или :рartent_id IN (JSON_EXTRACT(`parents`)) отлаживать запрос я не буду

никому тут не нужна нормальная форма - один SELECT с двумя условиями в WHERE, никакой сложности обновлений, никакой сложности выборки, никакой рекурсии, никаких JOIN, никаких точек, никаких паддингов, никакого collation, никакой сортировки, надо просто прочитать документацию

и никакая это не теория, а вопрос по mysql
 
Последнее редактирование:

fixxxer

К.О.
Партнер клуба
я очень сомневаюсь, что там mysql 8

в постгресе я бы вообще через массивы сделал
 

mihail.zagoskin

Новичок
для этой задачи может быть и просто lavel:int решает проблему, а json только испортит, если уж дерево то что-то стандартное
Пока разбираюсь во всем, сейчас у меня работает на обычной рекурсии с помощью поля parent_id. Мне выше советовали закешировать все, в принципе я так и сделал, кеширую структуру по уровням, 2 -> 4 -> 8 -> 32 -> ... Последний уровень не кеширую, так как там нужно всегда иметь актуальные данные. Плюс использую мемоизацию на функциях, которые нужно использовать не более одного раза. Пока такая солянка, работать стало быстрее, но проблема в актуальности данных иногда выскакивает, но и нагрузка на сервер не очень снизилась.
 

grigori

( ͡° ͜ʖ ͡°)
Команда форума
а доку по 5.7 посмотреть религия не позволяет?

в постгресе я бы вообще через массивы сделал
а в редисе - списком )))
в общем, это делается на чем угодно, задача стандартная, главное - не забывать лочить запись или работать в транзакциях, чтобы не поломать на состоянии гонки

@WMix я не знаю что такое lavel:int - опечатка
mihail.zagoskin "мемоизация" - это звучит сильно, но непонятно
 
Последнее редактирование:

WMix

герр M:)ller
Партнер клуба
С самого начала уровень на писался в базу. Мой просчет.
на самом деле "слева направо" может означать с учетом входа всех родителей, в этом случае order by insert_datum будет работать не коректно, а тогда без nested sets или materialized path с учетом того что писал выше @fixxxer никак не справиться

Код:
                  01.01
                   /\
                  /  \
                 /    \
                /      \
               /        \
              /          \
             /            \
            /              \
           /                \
        02.01              03.01
         /\                 /\
        /  \               /  \
       /    \             /    \
      /      \           /      \
     /        \         /        \
    /          \       /          \
  05.01       07.01  04.01       06.01
кому добавить в 04.01 или 05.01
 
Последнее редактирование:
Сверху