Комментарии на: Библиотека ORM_MPTT

От: Никита

Никита — Thu, 15 Oct 2009 02:50:59 +0000

Да, выглядит так:

$item = $tree->find($id);
$item->position($near_id, ‘auto|before|after’);

Разумеетя, $id и $near_id потомки одного родителя одного и того же уровня.

От: Никита

Никита — Thu, 15 Oct 2009 02:46:37 +0000

А я вчера написал метод position уже для твоего класса. Поделюсь с миром в ближайшее время

От: BIakaVeron

BIakaVeron — Wed, 14 Oct 2009 14:05:50 +0000

Да, плюс достаточно существенный, чтобы с ним считаться…
Насчет перемещения узла относительно другого – как есть метод insert_near(). Ну, и все идет к тому, что скоро появится метод exchange($node1, $node2)

PS. Правда, на данный момент я использую Ko3, так что навряд ли смогу быстро обновить класс для 2.3.4.

От: Никита

Никита — Wed, 14 Oct 2009 13:51:01 +0000

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

В чём один из люсов left_key и right_key у Nested Sets? Да в том, что по left_key как раз и можно делать сортировку ORDER BY!

От: BIakaVeron

BIakaVeron — Wed, 14 Oct 2009 10:17:53 +0000

Повторюсь, тут не имеет смысла реализовывать сортировку таким вот жестким способом. Добавьте к записи в БД поле “порядковый номер” (или “вес”, или еще как-нибудь). Вместо того, чтобы менять узлы местами “физически” (т.е. меняя их поля left и right), достаточно поменять значения данных полей. Не забывайте, что ветки 1.2 и 1.3 могут содержать достаточное количество дочерних узлов, а это увеличит количество обновляемых записей.
А вот перенести ветку в совсем другое место дерева (не в пределах одного общего родительского узла) – это да, имеет смысл. Но обычно при этом обмена не происходит, переносится только одна ветвь.
Все это, конечно, мое ИМХО.

От: Никита

Никита — Wed, 14 Oct 2009 09:48:22 +0000

“Ну, по сути это последовательные два вызова move_to(). Можно их реализовать в одном (уменьшится количество запросов), но часто ли они применяются?”

например, есть дерево:

- level1
– level 1.1
– level 1.2
– level 1.3
– level 1.4

Как тогда с помощью move_to() поменять level 1.2 и level 1.3 местами?

От: BIakaVeron

BIakaVeron — Mon, 21 Sep 2009 12:43:03 +0000

Представим себе две соседние ветки по 100 дочерних узлов в каждой. Чтобы поменять их местами, придется выполнить специальные (довольно затратные) запросы. А вот добавить к узлам поле order_num, которое будет управлять очередностью вывода веток – намного ведь проще. Разве не так? ИМХО, в пределах одного уровня ветки в принципе равнозначны, и не имеет смысла их менять местами (по крайней мере на стадии эксплуатации).

Хотя метод все равно надо будет добавить…

От: Sanpedro

Sanpedro — Mon, 21 Sep 2009 12:04:19 +0000

сортировка и иерархия хранимых данных вещи разные! но существуют как правило слитно – использование нестет деерва оправдано , а ORDER BY может “максимум” выводить детей в меню, отсортированными по алфавиту, не нарушая структуры ИМХО
Спасибо за ссылочку на DB Tree…
и Вам BlackaVeron, спасибо …

От: BIakaVeron

BIakaVeron — Mon, 29 Jun 2009 11:17:07 +0000

ИМХО, сортировка не имеет ничего общего с хранимыми в БД данными. Если сегодня одна категория выше, а завтра другая – постоянно менять их местами? Проще сделать дополнительное поле и сортировать (ORDER BY) по нему…

От: VKS

VKS — Mon, 29 Jun 2009 11:13:16 +0000

методы ChangePosition и ChangePositionAll в принципе вещи достаточно часто применяемые – допустим для сортировки категорий в каталоге.