Comments 18
Не совсем ясно почему в качестве теста взят запрос родителя родителя. А что будет если нужно узнать для произвольного элемента цепочку всех элементов до корневого элемента?
Я бы уточнил в реляционных базах данных. Ведь есть же графовые базы данных. Среди них бесплатные и достаточно стабильные (orientdb, arangodb). К сожалению они еще не и меют той стабильности и производительности что PostgreSQL и MySQL, но все что они предлагают в плате функционала это очень интересно.
Деревья в DB это один из самых острых вопросов при работе с данными
Я бы уточнил в реляционных базах данных. Ведь есть же графовые базы данных. Среди них бесплатные и достаточно стабильные (orientdb, arangodb). К сожалению они еще не и меют той стабильности и производительности что PostgreSQL и MySQL, но все что они предлагают в плате функционала это очень интересно.
0
так тоже проще. просто выбираем
SELECT * FROM tree
WHERE id != :id
AND array[id] && (
SELECT btree
FROM tree
WHERE id = :id
)
ORDER BY btree;
И опять обходимся без рекурсии. Можно так же самому достать id родителей и просто выбрать селектом с помощью команды IN
+1
Я бы уточнил в реляционных базах данных.Замечание по делу. Поправил. А работа с нереляционными базами данных — тема для отдельного топика. Они настолько разные, что наверное можно диссертацию написать.
0
Не имеют производительности Постгреса? Посмеялся. Очень громко. Плотно работаю с Нео4ж (comunity edition), никакой рсубд и рядом не лежал. Например дамп вконтакте с 450млн узлов и 15млрд связей — ищет кратчайшие пути длиной 6-10 за милисекунды.
0
Плотно работаю с Нео4ж (comunity edition)— Очень интересно, нужно будет попробовать. Спасибо за наводку.
0
Neo4j не рассматривал т.к. у них слишком строгая лицензия на community edition (персональное использование и внутри организации) что мне заведомо не подходит.
По производительности также (postgres vs orientdb) я рассматривал не только поиск но и вставку записей на одной машине без шардинга. Тут даже скорее на первое место выходит стабильность и надежность, чем только скорость.
По производительности также (postgres vs orientdb) я рассматривал не только поиск но и вставку записей на одной машине без шардинга. Тут даже скорее на первое место выходит стабильность и надежность, чем только скорость.
0
С каких пор GPL3 стала слишком строгой лицензией? Про OrientDB сложилось впечатление (по прочтении десятка тем на stackoverflow), что это глючный недоделанный мусор. ArangoDB потыкал палочкой и бросил. Явный лидер Neo4j. База 1ТБ (вышеупомянутый дамп ВК) собирается за 12 часов. РСУБД очень далеко до такого, про скорость поиска аналогично.
0
А что будет если нужно узнать для произвольного элемента цепочку всех элементов до корневого элемента?
В случае MP, разве это не то, что хранится для эл-та в поле btree? Ответ в таком случае будет
SELECT btree FROM tree WHERE id = :id
Или я заработался и не понял вопроса?
0
Наверное я что-то недопонял задавая вопрос. Сейчас посмотрел более внимательно наверное в btreе действительно хранится полный путь. Просто при прочтении статьи не нашел этого явно оговоренным.
0
Так уже сделано в виде расширения:
https://postgrespro.ru/docs/postgrespro/10/ltree
https://postgrespro.ru/docs/postgrespro/10/ltree
0
Да, спасибо. Просто не всегда можно использовать расширение (к примеру прав нет на установку). Да и сравнение без расширения более наглядно.
0
demiurg.livejournal.com/52346.html этот кейс не рассматривали?
0
Этот шаблон называется closure table.
Автор и NS как-то пропустил. Видимо NS и CT недостойны )
Автор и NS как-то пропустил. Видимо NS и CT недостойны )
0
SQL Trees. RALПо описанию автора все тот же самый добрый Materialized Path. Сделал бы по описанному выше методу — не пришлось бы ждать заполнения данных так долго. В моем случае миллион записей субъективно заполнилось за минут 20. Но сама попытка попробовать свое и приход к выводу хранения всех родителей очень хороший результат.
0
Sign up to leave a comment.
Снова о деревьях