Хранение иерархических структур. Симбиоз «Closure Table» и «Adjacency List»

[vintage]

А где же вариант «использовать более подходящую бизнес требованиям субд»? в данном случае, очевидно, стоило реляционную заменить на графовую

[crmMaster]

Что? Использовать отдельную СУБД для комметов только? Зачем увеличивать сложность системы, если можно просто немного подумать?

[vintage]

Количество «древовидных» моделей будет только увеличиваться. Дерево комментариев, граф друзей, таксономия разделов и тд и тп. Зачем в этих условиях вообще связываться с реляционными субд — ума не приложу.

[AStek]

Вы не совсем правы.

Современные реляционные СУБД вполне позволяют хранить в реляционной форме описание иерархических структур и делать по ним выборки. Тут рекомендую почитать про рекурсивные запросы. Не уверен поддерживает ли их MySQL но если даже нет то это проблема одного продукта а не всех реляционных баз.

[vintage]

Можно пример такого рекурсивного запроса?

[AStek]

www.postgresonline.com/journal/archives/131-Using-Recursive-Common-table-expressions-to-represent-Tree-structures.html
www.postgresql.org/docs/8.4/static/queries-with.html
habrahabr.ru/post/73700

можно найти и больше инфы.

Кроме того, я видел как такие вещи довольно успешно применяются в «энтерпрайзе», то есть это не отдельная малоизвестная фитчя.

[vintage]

Вы имеете ввиду что-то типа этого?

-- PostgreSQL --
WITH RECURSIVE temp1 ( "ID","PARENT","DESCRIPTION",PATH, LEVEL ) AS (
SELECT T1."ID",T1."PARENT", T1."DESCRIPTION", CAST (T1."ID" AS VARCHAR (50)) as PATH, 1
    FROM KPO T1 WHERE T1."PARENT" IS NULL
union
select T2."ID", T2."PARENT", T2."DESCRIPTION", CAST ( temp1.PATH ||'->'|| T2."ID" AS VARCHAR(50)) ,LEVEL + 1
     FROM KPO T2 INNER JOIN temp1 ON( temp1."ID"= T2."PARENT")      )
select * from temp1 ORDER BY PATH LIMIT 100

Сколько времени вам потребуется, чтобы понять, что тут происходит и где ошибка?

-- OrientDB --
select id , parent , description , $path , $depth from (
	traverse child from (
		select from kpo where id = 'KPO'
	)
)

А тут?

[AStek]

Если честно то имея опыт работы с первым я вполне понимаю что там происходит. И симметрично — я не представляю как работает второй пример. Хотя я не берусь утверждать что разобравшись с OrientDB не переменю свое мнение.

[vintage]

Попробуйте, там всё очень просто :-)

[crmMaster]

А если все перечисленное выше — дай бог 10% функциональности проекта?

Зачем в данном случае связываться с нереляционными СУБД — ума не приложу.

[vintage]

Можно пример такого проекта?

[crmMaster]

habrahabr.ru

[vintage]

Ой ли?

— все посты из хабов на которые подписан такой-то пользователь и всех подхабов и для каждого инфу о лайках, просмотрах, добавлениях в избранное, числе комментариев

— комментарии к такой-то публикации и для каждого информацию о том сколько и как их лайкнуло и как лайкнул их такой-то пользователь

— последние публикации сотни пользователей с максимальным рейтингом из такого-то региона

— список тэгов проставленных публикациям, в которых такой-то пользователь хотя бы один комментарий добавил в избранное

Страшно даже представить эти SQL запросы :-)

[crmMaster]

Это элементарные запросы, и если у вас проблемы с SQL, не надо тут свое профанство выпячивать.

[vintage]

Да-да, мы уже выяснили насколько они элементарные :-)

[drandin]

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

[vintage]

Вы так говорите, будто этому учиться нужно пару лет :-)

[youlose]

А где сравнение производительности?
Что-то мне подсказывает что апдейтить индексы на больших деревьях быстрее(для nested set), чем вставлять тысячи строк на каждую новую, а на небольших количествах данных (до 10 тысяч) разница мне кажется несущественна.

[AlexLeonov]

Интересно, что мешает добавить к полям Nested Sets еще parent и level и получить неограниченно масштабируемую структуру с преимуществами обоих моделей — и NS и AL? (Ну, кроме произвольной сортировки, ОК)
Всегда считал такой подход «золотым стандартом» для хранения древовидных структур. Я ошибаюсь?

[DEbuger]

А зачем хранить parent? Родителя можно получить по ключам left и right.
Сам использую Nested Sets для хранения дерева сайта, level нужен в моем случае, чтобы не крутить рекурсию для построения меню сайта, дерево сайта получается из одного запроса бд и одного цикла программного.

[AlexLeonov]

Для того, чтобы в любимой ORM можно было написать что-то вроде

'relations' => [
  'parent' => ['type' => 'belongsTo', 'model' => self::class, 'by' => '__parent_id']
]

и затем иметь возможность

$this->parent;

[greabock]

Про CT уже было на хабре, довольно неплохо расписано.