Снова о деревьях

[apapacy]

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

Деревья в DB это один из самых острых вопросов при работе с данными

Я бы уточнил в реляционных базах данных. Ведь есть же графовые базы данных. Среди них бесплатные и достаточно стабильные (orientdb, arangodb). К сожалению они еще не и меют той стабильности и производительности что PostgreSQL и MySQL, но все что они предлагают в плате функционала это очень интересно.

[Ihariv]

так тоже проще. просто выбираем

SELECT * FROM tree
WHERE id != :id 
AND array[id] && (
  SELECT btree 
  FROM tree 
  WHERE id = :id
)
ORDER BY btree;

И опять обходимся без рекурсии. Можно так же самому достать id родителей и просто выбрать селектом с помощью команды IN

[Ihariv]

Я бы уточнил в реляционных базах данных.

Замечание по делу. Поправил. А работа с нереляционными базами данных — тема для отдельного топика. Они настолько разные, что наверное можно диссертацию написать.

[mspain]

Не имеют производительности Постгреса? Посмеялся. Очень громко. Плотно работаю с Нео4ж (comunity edition), никакой рсубд и рядом не лежал. Например дамп вконтакте с 450млн узлов и 15млрд связей — ищет кратчайшие пути длиной 6-10 за милисекунды.

[Ihariv]

Плотно работаю с Нео4ж (comunity edition)

— Очень интересно, нужно будет попробовать. Спасибо за наводку.

[apapacy]

Neo4j не рассматривал т.к. у них слишком строгая лицензия на community edition (персональное использование и внутри организации) что мне заведомо не подходит.
По производительности также (postgres vs orientdb) я рассматривал не только поиск но и вставку записей на одной машине без шардинга. Тут даже скорее на первое место выходит стабильность и надежность, чем только скорость.

[mspain]

С каких пор GPL3 стала слишком строгой лицензией? Про OrientDB сложилось впечатление (по прочтении десятка тем на stackoverflow), что это глючный недоделанный мусор. ArangoDB потыкал палочкой и бросил. Явный лидер Neo4j. База 1ТБ (вышеупомянутый дамп ВК) собирается за 12 часов. РСУБД очень далеко до такого, про скорость поиска аналогично.

[crocodile2u]

А что будет если нужно узнать для произвольного элемента цепочку всех элементов до корневого элемента?

В случае MP, разве это не то, что хранится для эл-та в поле btree? Ответ в таком случае будет

SELECT btree FROM tree WHERE id = :id

Или я заработался и не понял вопроса?

[apapacy]

Наверное я что-то недопонял задавая вопрос. Сейчас посмотрел более внимательно наверное в btreе действительно хранится полный путь. Просто при прочтении статьи не нашел этого явно оговоренным.

[crocodile2u]

Ну просто так работает MP: хранит полный путь до корневого эл-та, в виде массива или строки, в зависимости от возможностей СУБД.

[LireinCore]

Так уже сделано в виде расширения:
https://postgrespro.ru/docs/postgrespro/10/ltree

[Ihariv]

Да, спасибо. Просто не всегда можно использовать расширение (к примеру прав нет на установку). Да и сравнение без расширения более наглядно.

[elmigranto]

Расширение встроено в постгрес, нужно просто сказать create extension и получить кучу операторов и правильную индексацию.

https://www.postgresql.org/docs/10/static/ltree.html

[Fortop]

demiurg.livejournal.com/52346.html этот кейс не рассматривали?

[greabock]

Этот шаблон называется closure table.
Автор и NS как-то пропустил. Видимо NS и CT недостойны )

[Ihariv]

NS я пропустил, поскольку он значительно сложнее и в добавлении записей и в последующем обслуживании.

[Ihariv]

SQL Trees. RAL

По описанию автора все тот же самый добрый Materialized Path. Сделал бы по описанному выше методу — не пришлось бы ждать заполнения данных так долго. В моем случае миллион записей субъективно заполнилось за минут 20. Но сама попытка попробовать свое и приход к выводу хранения всех родителей очень хороший результат.

[Ihariv]

точнее closure table — одна из разновидностей Materialized Path