Вступление.
myxtree - это интерфейс к sql дереву. Об sql деревьях написано достаточно много (см. ссылки), поэтому достаточно только упомянуть, что в myxtree используется модель вложенных множеств с добавлением ещё одного параметра depth (глубина).
Класс достаточно прост в использовании, в том смысле, что не требует много кодирования. В качестве входных данных для класса используется dom документ. Передаёте dom документ классу, и он сохраняет его в sql дереве. Для выборки данных из sql дерева используются xpath выражения. На выходе класса опять таки получаете dom документ.
Почему именно dom документ? Потому что он тоже имеет древовидную структуру. Потому что есть несколько способов получить dom документ. Это собственный api, с помощью которого можно построить структуру dom. Это xml документ, пропарсив который, вы можете получить dom. А также, результат трансформации xslt процессора это тоже dom документ. Таким образом, dom документ является сердцем всей технологии xml. Поэтому было решено ввести поддержку dom.
Однако, при простоте кодирования возникает опасность получить не тот результат который ожидался (это похоже на регулярные выражения - мало кода, большая функциональность, но пока добьёшся результата!). Для работы с классом необходимо знать язык xpath и хорошо понимать разницу между dom документом и sql деревом. Именно эти вопросы призвана осветить эта статья.
Добавление данных к sql дереву.
Это одна из самых простых операций. А если учесть что их всего четыре (добавление, изменение, выборка и удаление) то это целые 25% ;~).
Для начала нужно выполнить некоторые подготовительные операции.
< ?php // mydom входит в состав пакета myxml require_once('mydom/mydom.php'); // собственно сам myxtree require_once('myxtree.php'); // и абстрактный доступ к базам данных из pear репозитория require_once('db.php'); $dom = new document; // далее документ $dom необходимо наполнить содержимым одним из упомянутых // способом, например через dom api $dom->appendchild($dom->createelement('root')); // и т.д. // создаём подключение к базе данных $db = db::connect("mysql://$user:$pass@$host/$name"); // переменные $user, $pass и др. конечно же, подставить ваши // и наконец создаём обьект класса myxtree $xtree =& myxtree::create($db, $prefix); pear::iserror($xtree) and trigger_error($xtree->getmessage(), e_user_error); // параметр $prefix можно не указывать, это префикс имён таблиц базы данных // результат, возвращаемый методом myxtree::create лучше проверить, вдруг база // данных не является базой myxtree или не той версии ?>
Теперь всё готово для следующих операций.
Итак, добавление. Метод insert() принимает три параметра. Первый параметр $node - это объекты типа element_node, text_node, cdata_section_node и attribute_node. Другие типы из стандарта dom в базе данных не сохраняются. Почему? Потому что пока не было необходимости. А во вторых - не всё получается сохранить (подробности позже).
Вторым параметром указывается объект, к которому необходимо добавить объект $node указанный в первом параметре. Так как только у element_node могут быть дети, то соответственно, в параметре $parent можно передавать только эти объекты. Кроме того $parent уже должен существовать в базе данных, иначе будет выдано сообщение об ошибке. Возникает вопрос, где взять объект класса element который находился бы в базе данных. Правильнее будет задать вопрос как создать объект класса element и установить соответствие между этим объектом и записью в базе данных. Такая постановка вопроса - это суть работы класса myxtree. Ему постоянно приходится устанавливать соответствие между объектами dom документа и записями в базе данных. И ему требуется от вас некоторая помощь (но об этом тоже позже). Если вы будете помнить об этом утверждении, то вам значительно легче будет работать с классом.
Так вот, myxtree сам создаст объект класса element и установит соответствие между этим объектом и записью в базе данных. Он сделает это для вас, если вы его попросите, вызвав метод select(). Проще говоря, по xpath выражению вы выбираете необходимый вам узел (node) и получаете готовый объект, который и подставляете в параметре $parent.
Но тут возникает второй законный вопрос, где взять объект $parent если база данных ещё пуста. Ответ прост. Она не пуста. Там уже есть корень (root). Его всегда можно выбрать по xpath выражению "/", но делать этого не нужно. По умолчанию, если $parent не задан, $node добавляется в корень sql дерева. И таких можно добавить достаточно много.
И, наконец, третий параметр - $deep (глубоко), указывает на то что необходимо добавить также всех потомков объекта $node (т.е. можно добавить только объект $node с атрибутами, не смотря на то что у него есть потомки).
Давайте, наконец, посмотрим, что у нас делается в примере.
< ?php // Ну вот. Как я и говорил, можно добавлять прямо в корень. // В качестве первого параметра $node передаём объект $dom->documentelement, а // не $dom, так как $dom имеет тип document_node. $result = $xtree->insert(&$dom->documentelement, $parent = null, $deep = true); pear::iserror($result)) and trigger_error($result->getmessage(), e_user_error); // Обязательно проверим успех нашего действия. ?>
Конечно же, вместо $dom->documentelement можно было бы вставить любую часть документа dom. Просто у нас в примере её нет.
Удаление данных.
По логике вещей сейчас нужно было бы рассказать о выборке или обновлении, но удаление, это следующая, ещё более простая операция.
Метод delete() принимает только один параметр $node который необходимо удалить. Причём, если у $node в базе есть потомки, они тоже удаляются. Конечно же, объект должен существовать в базе, а получить его можно также, с помощью метода select().
< ?php // Удалим, например тот же $dom->documentelement. Причём, так как мы его только // что вставляли, соответствие между ним и записью в базе данных уже установлено. // Это я к тому, что не нужно выбирать его из базы методом select(); $result = $xtree->delete(&$dom->documentelement); pear::iserror($result) and trigger_error($result->getmessage(), e_user_error);
Выборка данных.
Здесь нам понадобится хорошее понимание языка xpath.
Для выборки данных sql дерева по xpath выражению используется метод select(). Первый параметр, который принимает этот метод, это строка - выражение xpath. Второй параметр указывает на метод, которым необходимо обработать xpath выражение. Назначение этого параметра станет понятным позднее. Так же как и метод evaluate() для dom документа, select() возвращает массив ссылок (references) на объекты node. Но, кроме этого, метод select() воссоздаёт дерево объектов node. Пример поможет лучше понять разницу.
Для начала необходимо уточнить разницу между терминами xml документ и dom документ. xml документ - это определённым образом отформатированный текст. Таким образом, ниже приведенный пример - это xml документ. dom документ - это древовидная структура объектов в памяти компьютера. Т.е. dom документ используется для представления xml документа в памяти компьютера. Каждый объект, в структуре dom документа имеет ссылки на соседние объекты. А именно previoussabling (предшествующий брат), nextsibling (последующий брат), firstchild (первый ребёнок), lastchild (последний ребёнок) и некоторые другие.
< root> < node-1-1> < node-1-2> simple text < /node-1-2> < node-2-2> < node-1-3> very simple text < /node-1-3> < /node-2-2> < /node-1-1> < /root>
В этом примере предшествующим братом для узла node-2-2 будет узел node-1-2, а node-2-2 соответственно будет последующим братом для узла node-1-2. Первым ребёнком для узла node-1-1 будет узел node-1-2, а последним node-2-2. А текстовый узел "simple text" будет первым и последним ребёнком для узла node-1-2. Именно таким способом определяется дерево dom документа.
Что же сделает xpath процессор, если мы попросим его найти узлы, у которых есть ребёнок типа text_node ("//node()[text()]"). Он пробежится по дереву и вернёт нам узлы node-1-2 и node-1-3 в виде массива ссылок. Обратите внимание, не копии объектов, а ссылки на них. Не древовидную структуру, а список (одномерный массив). Имея ссылку на объект, который находится в дереве, мы легко можем получить доступ к другим объектам через previoussibling, firstchild и т.д.
Что же сделает xpath процессор класса myxtree? Он откомпилирует xpath выражение в sql запрос, выполнит его и получит массив с записями базы данных. По этим записям он создаст объекты определённого типа (element_node, text_node и т.д.) и тоже вернёт в виде списка ссылок на объекты. Но, кому они нужны в таком виде? Для того чтобы они стали полезными необходимо восстановить отношения предок-потомок, т.е. воссоздать дерево объектов. Метод select() делает и это. Но, именно здесь и заключается большая разница в использовании xpath выражений для dom документа и для sql дерева.
Дело в том, что метод select() воссоздаёт дерево из того, что было возвращено запросом. Например, выражение "//node()[text()]" вернёт только узлы node-1-2 и node-1-3. Так как они не связаны непосредственно друг с другом, то дерева из них не получиться. Кроме того, текст "simple text" и "very simple text" это отдельные текстовые узлы, которые тоже не возвращаются выражением "//node()[text()]". Поэтому практика использования xpath выражений для sql дерева отличается от dom дерева. Например, для того чтобы текстовые узлы попали в результат выражения, нужно дописать его - "//node()[text()]//". Таким образом, метод select() вернёт список ссылок уже на четыре объекта и воссоздаст два фрагмента дерева.
Осталось только сказать, что для того чтобы select() мог создать объекты node ему необходимо указать dom документ. А для того чтобы воссоздать дерево объектов, необходимо также указать объект (reception node) в который будет помещено это дерево.
А теперь пример.
< ?php // Создаём узел, к которому будет добавлено воссозданное дерево. $resultnode =& $dom->createelement('resultnode'); // Даём знать об этом объекту класса myxtree. $xtree->setreceptionnode(&$resultnode); $nodeset = $xtree->select("//node-1-1//"); pear::iserror($nodeset) and trigger_error($nodeset->getmessage(), e_user_error);
В результате выполнения метода select() узел $resultnode будет содержать узел node-1-1 вместе со всеми потомками, а $nodeset будет содержать список ссылок на узел node-1-1 и всех его потомков. В зависимости от конкретных потребностей вы можете использовать тот или другой способ получения результата.
Обновление данных.
А здесь предстоит разобраться с проблемой сравнения двух xml документов.
Почему именно xml документов, а не dom документов? Потому что обмен данными происходит именно в xml формате. Нам необходимо обеспечить возможность получить данные sql дерева, отправить для изменения пользователю, а потом полученные изменения внести обратно в sql дерево. Отправление данных пользователю и получение их обратно будет происходить в xml формате (xforms на пороге).
Давайте на некоторое время забудем про sql дерево и представим, что мы имеем дело с бо-о-ольшим xml документом.
Это будет наш бо-о-ольшой А это та часть которая была
документ изменена пользователем
< root> < node-1-1 id="1"> < node-1-1 id="1"> < node-1-2> < node-1-2> simple text unsimple text < /node-1-2> < /node-1-2> < node-2-2> < /node-1-1> < node-1-3> very simple text < /node-1-3> < /node-2-2> < /node-1-1> < /root>
Для того чтобы внести изменения нам необходимо установить соответствие между этими двумя xml документами. Так как xml документ это дерево, элементы определяются своим положением в дереве. Этот способ нам не подходит. Имя элемента тоже не может служить идентификатором. Можно для этой цели использовать атрибут. Но текстовые узлы и узлы cdata не могут иметь атрибутов. Так как выбирать больше не из чего, было решено использовать атрибут с именем "id" уникальный в пределах всего дерева. А для идентификации текстовых и cdata узлов использовать атрибут "id" их родителя. Следствием такого решения стало то, что элементы должны иметь только одного ребёнка типа text_node или cdata_section_node. Кроме того, если узел типа element_node не имеет атрибута "id", также будет выполнена попытка идентифицировать его по атрибуту "id" родителя и по имени самого элемента. Есть ещё способ идентификации элемента по атрибуту "id" и по имени элемента. Т.е. атрибут "id" в таком случае должен быть уникальным только в пределах указанного имени. Данный способ не реализован в myxtree.
Итак, мы определились ЧТО обновлять. Теперь нужно разобраться, КАК обновлять. Самое простое, что приходит в голову это заменить одно на другое. Т.е. (см. пример выше) заменить узел node-1-1 в большом xml документе на соответствующий. Назовём этот способ полным обновлением (при таком способе обновления нам нет нужды беспокоится о соответствии дочерних элементов, достаточно чтобы только узел node-1-1 имел атрибут "id"). Однако в большом xml документе у узла node-1-1 есть ещё один дочерний элемент node-2-2, при таком способе обновления он будет удалён из дерева. В тех случаях, когда пользователю позволено менять структуру дерева, нам именно это и нужно. Однако возникают ситуации, когда нужно обновить только часть потомков узла node-1-1. В таком случае нам нужно использовать выборочное обновление. При таком способе обновляться будут только те узлы, которые были реально изменены. Если появились новые элементы, они будут добавлены. Такой алгоритм обновления ещё не окончательный вариант. В основном он сложился в ходе решения конкретной задачи. И тут будут интересны ваши мнения.
Само использование метода update() не представляет никаких сложностей. Первый параметр - это узел, который нужно обновить, второй параметр указывает на то что обновить нужно не только указанный элемент но и потомков, третий параметр определяет способ обновления: true - полное, false - выборочное.
< ?php $result = $xtree->update(&$dom->documentelement, $deep = true, $full = false); pear::iserror($result) and trigger_error($result->getmessage(), e_user_error);
Если алгоритм обновления вас не устраивает, всегда остаётся возможность "ручного" поочерёдного обновления. В таком случае параметр $deep должен быть false.
Немного о работе класса.
Выше упоминался параметр $recursive для метода select(). Пришло время рассказать об этом поподробнее.
Чем хороши sql деревья с моделью вложенных множеств? Тем, что за один sql запрос можно получить узел со всеми его потомками независимо от глубины вложения. Чем плохи sql деревья? Тем, что составить такой sql запрос, мягко говоря, непросто. В тоже время существует хороший язык запросов к древовидным структурам - xpath. Так было решено попробовать использовать язык xpath для sql деревьев. Получилось. Но какой ценой?
При построении sql запроса по xpath выражению используется самообъединение таблиц. Например, выражение "/root" создаст sql запрос вида:
select * from objects, objects as table1, objects as table2 where ...
Самообъединение означает, что таблица будет помножена на саму себя. Т.е. таблица из 100 строк породИт 10000 строк! Страшная цифра! Такой результат ставил под сомнение целесообразность всего проекта. Поэтому был реализован ещё и другой способ обработки xpath выражения - рекурсивный. Название второго способа говорит само за себя.
После того как класс заработал, было проведено соревнование между первым (selfjoin) и вторым (recursive) способом, в результате которого самообъединение было реабилитировано! Трудно сказать каким способом, но mysql с успехом справляется с этой огромной задачей. Тут интересно было бы мнение специалистов по mysql.
Вместе с классом myxtree распространяются также тестовые файлы, на которых и сравнивалась работа класса двумя способами. В тесте сперва создаётся dom документ из 1000 элементов. Потом этот документ сохраняется в sql дереве, и, наконец, методом select() производится выборка элементов двумя способами. В качестве запросов используются выражения вида "/*", "/*/*", "/*/*/*" и т.д. до десяти уровней вложенности. Реально dom документ имеет 5 уровней вложенности. Причём в одном случае у каждого элемента есть только по одному дочернему элементу, а в другом по 5. Т.е. количество выбираемых элементов растёт с каждым уровнем. И в том и в другом варианте способ самообъединения таблиц превосходил рекурсивный способ.
В погоне за скоростью.
Наверно многие захотят поинтересоваться, как быстро это всё работает?
Вопрос слишком неоднозначный чтобы на него можно было ответить однозначно. Какие критерии оценки использовать? Узнать конкретное время выполнения вы можете на своём компьютере, запустив тесты прилагаемые к myxtree. Можно было бы сравнить скорость работы myxtree с другим классом с подобной функциональностью, но на сегодняшний день мне такие не известны. Есть интерфейсы к sql деревьям, но без поддержки dom и xpath. А это в свою очередь сказывается на скорости (чем больше функциональность, тем меньше скорость). Есть и ещё один критерий оценки - скорость разработки. Причём время, затраченное на разработку, стоит значительно дороже, чем время выполнения скрипта. Сколько вы потратите времени, чтобы сделать скрипт работающий на полсекунды быстрее. Стоит ли это тех усилий. myxtree поможет сэкономить время разработки. Стоит только один раз разобраться с ним. Как говориться "лучше полдня учиться летать, а потом за пять минут долететь", ведь навык летать останется.
Постоянные ссылки
При копировании ссылка на TeaM RSN обязательна!
Оставить комментарий
Вы должны войти, чтобы оставить комментарий.