Pull to refresh

Comments 18

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

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

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


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

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

Я бы уточнил в реляционных базах данных.
Замечание по делу. Поправил. А работа с нереляционными базами данных — тема для отдельного топика. Они настолько разные, что наверное можно диссертацию написать.
Не имеют производительности Постгреса? Посмеялся. Очень громко. Плотно работаю с Нео4ж (comunity edition), никакой рсубд и рядом не лежал. Например дамп вконтакте с 450млн узлов и 15млрд связей — ищет кратчайшие пути длиной 6-10 за милисекунды.
Плотно работаю с Нео4ж (comunity edition)
— Очень интересно, нужно будет попробовать. Спасибо за наводку.
Neo4j не рассматривал т.к. у них слишком строгая лицензия на community edition (персональное использование и внутри организации) что мне заведомо не подходит.
По производительности также (postgres vs orientdb) я рассматривал не только поиск но и вставку записей на одной машине без шардинга. Тут даже скорее на первое место выходит стабильность и надежность, чем только скорость.
С каких пор GPL3 стала слишком строгой лицензией? Про OrientDB сложилось впечатление (по прочтении десятка тем на stackoverflow), что это глючный недоделанный мусор. ArangoDB потыкал палочкой и бросил. Явный лидер Neo4j. База 1ТБ (вышеупомянутый дамп ВК) собирается за 12 часов. РСУБД очень далеко до такого, про скорость поиска аналогично.
А что будет если нужно узнать для произвольного элемента цепочку всех элементов до корневого элемента?

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


SELECT btree FROM tree WHERE id = :id

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

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

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

Да, спасибо. Просто не всегда можно использовать расширение (к примеру прав нет на установку). Да и сравнение без расширения более наглядно.
Этот шаблон называется closure table.
Автор и NS как-то пропустил. Видимо NS и CT недостойны )
NS я пропустил, поскольку он значительно сложнее и в добавлении записей и в последующем обслуживании.
SQL Trees. RAL
По описанию автора все тот же самый добрый Materialized Path. Сделал бы по описанному выше методу — не пришлось бы ждать заполнения данных так долго. В моем случае миллион записей субъективно заполнилось за минут 20. Но сама попытка попробовать свое и приход к выводу хранения всех родителей очень хороший результат.
точнее closure table — одна из разновидностей Materialized Path
Sign up to leave a comment.

Articles