Статья на редкость интересная. Не в том смысле, что интересные фрагменты встречаются редко.
Порадовали конкретные SQL-запросы для выполнения конкретных задач.
Скажите, а кто-либо использует эту схему для своих сайтов?
Интересует, как nested sets можно сравнить со схемой, которая применяется для GForge (
http://gforge.org/):
id_topic Номер узла, auto_increment, наш primary key.
sort_order Порядок сортировки, +/- 10.
id_parent Вышестоящий узел.
id_parent_root Вышестоящий узел второго уровня вложенности. Если для данного узла такого уровня нет - тогда 0.
cnt_subtopic Количество узлов внутри данного узла. Для вывода на экран "тема такая-то (10)"
ids_fullpath Полный путь узла, разделенный каким-нибудь простым способом. Например запись " 10 :: 23 :: 45 " означает "45-й узел внутри 23-го, 23-й внутри 10-го, 10-й - самый главный и он же в id_parent_root)
Выбор фрагмента ветки любого уровня производится с помощью запроса:
SELECT ids_fullpath FROM table
WHERE ids_fullpath LIKE "% 23 %"
Пример полученного списка:
10 :: 23
10 :: 23 :: 45
10 :: 23 :: 45 :: 50
Выбор всей ветки:
SELECT ids_fullpath FROM table
WHERE id_parent_root = "10"
Обновление и добавление несложное - одна php-функция просто добавляет строку
без ids_fullpath, другая - рекурсивная, пересчитывает ids_fullpath
для только что вставленного id_topic и, если потребуется, для всей ветки, начиная c последнего узла (45),
заканчивая первым, root (10).
Содержимое таблицы:
id_topic id_parent id_parent_root cnt_subtopic ids_fullpath
10 0 0 3 10
23 10 10 2 10 :: 23
45 23 10 1 10 :: 23 :: 45
50 45 10 0 10 :: 23 :: 45 :: 50
Примерно такая схема применяется сегодня на sourceforge.net, freshmeat.net.
Только там базы PostgreSQL, поэтому значение для поля cnt_subtopic
вычисляется автоматически при обновлении дерева с помощью хранимой процедуры.
