ST
Может хоть про ER что-то слышали? Там концептуальное проектирование
Size: a a a
2021 June 07
SP
а зачем эти кастыли? Если у тебя графы то лучше графовую базу брать. А если деревья с уровнем вложенности пара десятков - просто adjacency list + ну если ооооочень надо оптимизировать какие-то выборки materialized path.
SP
всегда воспринимал все эти nested sets больше как занятную задачку "как из буханки хлеба сделать троллейбус"
SP
по сути тебе это на уровне мэппинга надо делать или тригерами в базе если оч хочется
СП
Ну с точки зрения предметной области есть родитель. Поэтому так)
ST
Для OLAP неплохо, не надо целостность, не надо дырки расширять
СП
materialized path - это в отдельной колонке в строке хранить путь к текущему элементу, верно?
SP
да, что бы order by и не выпендриваться и скорость вставки больше
СП
Как быть если в качестве id используются UUID, из них составлять путь, это норм?
SP
а какая разница, строка она и в африке строка
SP
можно еще много чего придумывать, например хранить всех предков в jsonb. если нужно оч быстро находить всех детей такого предка. Но это от СУБД зависит
СП
Никогда не сталкивался с этим. Решил уточнить :)
ST
А для nested set это это норм что ли? :D
SP
ну там то отдельные ключики для выстраивания дерева так что...
ST
там нужна гарантированная упорядоченность, чтобы ноды попадали в нужный интервал
SP
ST
т.е. c UUID ничего кроме "списка смежности" и "подмножеств" не будет работать. Мат.пути - теоретически можно, но практически не нужно
СП
Для них вообще не важно же какой ID
ST
Идем читать про nested set по ссылке
СП
я рассматривал вариант. когда мы храним номера узлов и при перемещении их пересчитываем