А еще этот прикол с покраской колёс на БТРе, например.

У Roboto заметил проблему с буквами «ц», и «щ» в некоторых начертаниях.

А еще можно было бы использовать data:uri.

Оу, уже хочу портировать на PHP :)

вот это-то как раз было бы классно для новостных ресурсов например :)

Еще одно полезное замечание! Учту это в следующих версиях библиотечки ;)

У меня превращение плоского списка с записями дерева в «настоящее» дерево программно решено: после выборки происходит превращение.

Так у меня на нее и ссылка в начале статьи :)

Как-то помнится на четвертом курсе я писал блог на CodeIgniter (PHP) в качестве ВКР, тоже использовал parent_id. Вот там выверты были с рекурсивным составлением запросов для выборки веток…

Есть такое дело. Хотя, в принципе, такую вещь можно было бы применить и к другим методам хранения деревьев. Разве что не к Adjacency List, наверное.

Очень ценные замечания! Честно говоря, не задумывался об этом. Исходил из того, что ORM в различных фреймворках зачастую оперируют таблицами, оставляя выбор добавления ключей за пользователем. Теперь будет пища для размышлений и реализации обозначенного вами в следующих версиях моей библиотечки :)

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

Да, конечно, просто не так понял вопрос!

Мне как раз наоборот субъективно кажется, что у Closure Table запросы попроще :) И еще нравится, что связи отделены от самих сущностей.

Фишка как раз в уходе от поля parent, в уходе от рекурсии и большого количества join-ов. Обратите внимание, что любой из приведенных запросов использует всего лишь один join. И дерево по такой таблице связей строится достаточно легко.

А что касается проблем с целостностью, то я думаю, что это зависит от реализации интерфейса по работе с такой системой. Если интерфейс правильно организован, пользователь не сможет нагородить огород и всё поломать.

Так если и есть, то не везде. Это один из универсальных способов наряду с перечисленными в начале статьи.

Так в таблице pages_treepath оно ведь дублироваться будет. А так ведь страницы, категории и прочие — сортируемые ведь вещи. И к связям сортировка имеет лишь то отношение, что по позиции можно выбрать предыдущие или следующие элементы (prev siblings, next siblings).

Нет, таблица treepath хранит все связи. То есть каждый предок хранит информацию о своих дочерних элементах. В данном случае получится следующая таблица:

ancestor | descendant | level
------------------------------
    1          1           0
    2          2           0
    3          3           0
    4          4           0
------------------------------
    1          2           1
    2          3           1
    3          4           1
------------------------------
    1          3           2
    2          4           2
------------------------------
    1          4           3

В статье забыл об этом упомянуть. За порядок может отвечать поле position, которое следует добавить в таблицу pages. От нуля и до бесконечности. В своей реализации я так и сделал.