LINUX.ORG.RU

Как лучше построить дерево в SQL?

 ,


1

2

Погуглив и наткнувшись на stackoverflow узнал, что деревья бывают 3х видов.

Рекурсивные - это когда создаешь элемент, потом еще один элемент и устанавливаешь ему родительский, у этого элемента еще один и указываешь предыдущий родительским и т.д... где рисуется дерево в результате рекурсии.

Вложенные(?), это какие-то там left right ячейки в таблицах, как это работает - ЯННП. Фиг с ними, значит оно нам не нужно(?).

Материализованные - это обычные пути, например пять сообщений с ID 1 2 3 4 5, и влажения представлены в виде путей: /1/2/4 /3/5

Кажется, использовать классические пути самое простое в плане производительности: один SQL запрос с выборкой LIKE по маске /1/* например. Но при добавлении новой записи в таблицу, это ж наверно придется обновлять все значения в таблице?
Я нуб в SQL и просто не знаю какой алгоритм лучше взять.

★★★★★

Рекурсия - самый простой и безвредный способ. Чем не устраивает?

schizoid ★★★
()

Сорри за орфографию, пишу с планшета, из сортира.

Самый простой с точки зрения заполнения - первый, но он самый неэффективный и простым запросом дерево не выберешь. Либо писать процедуру, либо стэк запросов (или вообще селектнуть все и разгребать в приложении в случае маленького)

Второй называется нестед лист - имхо самый сбаллансированный. Его, при некоторых навыках, можно распарсить глазами и с апдейтами геммора не так уж и много. Его суть в том, что хранить нужно только оффсеты. У каждого элемента 2 границы, к примеру, (элемент 9-10) и (элемент11-12) являются ветками элемента (8-13) он включает в себя границы первых двух. Эти множества не пересекаются. А самый корень будет (1-максправаяграницавложенного+1). Чтобы выбрать ветку, надо взять просто все что попадает ввнутрь. Вставка между = апдейт+2 к границам последующих элементов.

Третий прост с точки зрения «посмотреть в пхпадмине», но относительно геммороен при вставке «между», тебе придется строковыми функциями перефигачивать все что дальше.

BaBL ★★★★★
()
Ответ на: комментарий от BaBL

окей. возьму 3й способ, т.к. как раз самый простой для чтения. писать «между» не нужно.

с облегчением.

Spoofing ★★★★★
() автор топика
Ответ на: комментарий от Spoofing

третьи, но лучше выбрать годную библиотеку, mptt для джанги, например

trashymichael ★★★
()
Ответ на: комментарий от BaBL

Самый простой с точки зрения заполнения - первый, но он самый неэффективный и простым запросом дерево не выберешь.

Зависит от базы. Как минимум Oracle поддерживает следующие SQL конструкции для работы с таким типом деревьев:

start with
и
connect by

Ja-Ja-Hey-Ho ★★★★
()

самое простое в плане производительности: один SQL запрос с выборкой LIKE

LIKE — это одна из самых медленных процедур в СУБД

Вложенные(?), это какие-то там left right ячейки в таблицах, как это работает - ЯННП.

Ну, почитай здесь: http://www.getinfo.ru/article610.html

Wizard_ ★★★★★
()
Ответ на: комментарий от annulen

у монго есть киллер-фича - оно чем-то похоже на sql. http://docs.mongodb.org/manual/reference/sql-comparison/ Т.е. команду, которая не хочет переучиваться, можно заманить тем, что «переучиваться» придется не сильно. Даже если это неправда :3

stevejobs ★★★★☆
()
Ответ на: комментарий от stevejobs

А почему просто не взять Mongo и пусть оно само это говно разруливает?

А ничего, что там по ссылке монго ничего само не разруливает, а просто описаны примеры того, как делать всё руками? Причем те же, что и у автора в исходном посте.

risenshnobel ★★★
()
Ответ на: комментарий от stevejobs

ага, только после того как построил, этим говном еще и пользоваться надо как-то

Вот уж чего-чего, а методы работы с деревьями по указанным алгоритмам отличаются в nosql и sql очень мало. Монга никаких чудес тут не добавляет, увы.

risenshnobel ★★★
()
Ответ на: комментарий от risenshnobel

ты можешь плодить деревья на любой чих. хоть с помощью автоматической интроспекции клиентского кода. И менять структуру как бох на душу положит, в рантайме разберемся. Все это можно спрятать под парой слоев абстракции, чтобы совсем уж не включать мозга. Да, будет тормозить, ну и черт с ним! Зато возможно. А в SQL даже с Hibernate это сложно. Я пробовал с Hibernate делать динамическую генерацию БД, и обратно - автоматический реверс-инжиниринг кода на Java по известной базке. Чтобы был интерфейс: «на тебе граф объектов, сохрани мне его как-нибудь», и «у меня есть какие-то названия таблиц, дай мне из них граф каких-нибудь объектов? (сам выберешь каких, ты же умный)». Ниасилил: тормозно, сложно реализуемо, плохо работает. Не видел никого, кто бы это действительно использовал. В результате целый класс «алгоритмов» теоретически существует, а практически никто их не юзает.

stevejobs ★★★★☆
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.