паддинг тут еще и для сортировки, с точками так просто не получится order by же?Кстати, падить нулями не нужно, точка-разделитель прекрасно работает.
а вообще идея в varbinary и pack(), строками для читаемости написал
паддинг тут еще и для сортировки, с точками так просто не получится order by же?Кстати, падить нулями не нужно, точка-разделитель прекрасно работает.
Ну я вот как раз сортировку-то и имел в виду - она с точками работает.паддинг тут еще и для сортировки, с точками так просто не получится order by же?
Хм. какой-то хитрый collation?Ну я вот как раз сортировку-то и имел в виду - она с точками работает.
чаще всего это не важно, достаточно pid, сортировка будет у клиента и там дата создания и имя в алфавитном порядке и другое, важнее инструмент поиска близкий к [n] иметьПо дефолту будет так, как я и думал
Блин, а как же у меня работало. или не работало?...По дефолту будет так, как я и думал
мы тут вроде конкретную задачу решаем а не абстрактную =)чаще всего это не важно, достаточно pid, сортировка будет у клиента и там дата создания и имя в алфавитном порядке и другое, важнее инструмент поиска близкий к [n] иметь
ну наверное тебе была нужна сортировка с учетом вложенности, а порядок не так важенБлин, а как же у меня работало. или не работало?...
ну да, сначала свободный с наименьшем уровнем, дальше в любой ветке с наименьшей датоймы тут вроде конкретную задачу решаем а не абстрактную =)
для этой задачи может быть и просто lavel:int решает проблему, а json только испортит, если уж дерево то что-то стандартноеJSON_SEARCH(`parents`,'all',:рartent_id) AND JSON_LENGTH(дочки)<4
да 5.7я очень сомневаюсь, что там mysql 8
в постгресе я бы вообще через массивы сделал
Пока разбираюсь во всем, сейчас у меня работает на обычной рекурсии с помощью поля parent_id. Мне выше советовали закешировать все, в принципе я так и сделал, кеширую структуру по уровням, 2 -> 4 -> 8 -> 32 -> ... Последний уровень не кеширую, так как там нужно всегда иметь актуальные данные. Плюс использую мемоизацию на функциях, которые нужно использовать не более одного раза. Пока такая солянка, работать стало быстрее, но проблема в актуальности данных иногда выскакивает, но и нагрузка на сервер не очень снизилась.для этой задачи может быть и просто lavel:int решает проблему, а json только испортит, если уж дерево то что-то стандартное
а в редисе - списком )))в постгресе я бы вообще через массивы сделал
да обычное кеширование. В гугле определение увидал))@mihail.zagoskin "мемоизация" - это звучит сильно, но непонятно
С самого начала уровень на писался в базу. Мой просчет.level
-- where is_free order by level, insert_date
Это боль)).в общем, это делается на чем угодно, задача стандартная, главное - не забывать лочить запись или работать в транзакциях, чтобы не поломать на состоянии гонки
на самом деле "слева направо" может означать с учетом входа всех родителей, в этом случае order by insert_datum будет работать не коректно, а тогда без nested sets или materialized path с учетом того что писал выше @fixxxer никак не справитьсяС самого начала уровень на писался в базу. Мой просчет.
01.01
/\
/ \
/ \
/ \
/ \
/ \
/ \
/ \
/ \
02.01 03.01
/\ /\
/ \ / \
/ \ / \
/ \ / \
/ \ / \
/ \ / \
05.01 07.01 04.01 06.01