Comments 22
А где же вариант «использовать более подходящую бизнес требованиям субд»? в данном случае, очевидно, стоило реляционную заменить на графовую
Что? Использовать отдельную СУБД для комметов только? Зачем увеличивать сложность системы, если можно просто немного подумать?
Количество «древовидных» моделей будет только увеличиваться. Дерево комментариев, граф друзей, таксономия разделов и тд и тп. Зачем в этих условиях вообще связываться с реляционными субд — ума не приложу.
Вы не совсем правы.

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

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

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

-- 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'
	)
)

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

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

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

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

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

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

Страшно даже представить эти SQL запросы :-)
Это элементарные запросы, и если у вас проблемы с SQL, не надо тут свое профанство выпячивать.
Для того чтобы использовать графовую базу данных в проекте, нужно иметь разработчиков, которые с ней умеют работать.
А где сравнение производительности?
Что-то мне подсказывает что апдейтить индексы на больших деревьях быстрее(для nested set), чем вставлять тысячи строк на каждую новую, а на небольших количествах данных (до 10 тысяч) разница мне кажется несущественна.
Интересно, что мешает добавить к полям Nested Sets еще parent и level и получить неограниченно масштабируемую структуру с преимуществами обоих моделей — и NS и AL? (Ну, кроме произвольной сортировки, ОК)
Всегда считал такой подход «золотым стандартом» для хранения древовидных структур. Я ошибаюсь?
А зачем хранить parent? Родителя можно получить по ключам left и right.
Сам использую Nested Sets для хранения дерева сайта, level нужен в моем случае, чтобы не крутить рекурсию для построения меню сайта, дерево сайта получается из одного запроса бд и одного цикла программного.
Для того, чтобы в любимой ORM можно было написать что-то вроде

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


и затем иметь возможность
$this->parent;
Only those users with full accounts are able to leave comments. Log in, please.