Вопрос в том, что при использовании разных framework с разными «обертками» работы с БД этот класс придется постоянно перестраивать, если он будет участвовать в цепочке наследования или как плагин.
При работе с несколькими языками программирования — то же самое.
Еще раз повторюсь.
Я до недавнего времени использовал подобные классы как плагины, но я посчитал, что перевод этого алгоритма на более низкий уровень более оправдано, ввиду использования в работе новых технологий.
А что используете вы, товарищ? Рекурсивные деревья?
PostgreSQL — тут не при чем, статья по нему по соседству.
ltree — не самое лучшее решение, особенно в части переноса веток, и подсчета.
Вообще, я бы предложил таки посмотреть код и понять, что там происходит, но вкратце, объясню.
Большую часть кода триггер вычисляет координаты, т.к. решение смешанное, то в качестве конечной координаты может быть parent_id, как в рекурсивных деревьях, так и left_key для деревьев Nested Sets. Отсюда немного усложненная логика вычисления координат.
При известных координатах вообще-то достаточно двух запросов для каждого из действий. Причем для перемещения, реально выполняется только один запрос обновления, а два их только потому, что они разные для направления перемещения.
Что лучше, держать этот геморрой у себя в приложении или прицепить этот триггер на таблицу в которой у нас дерево и забыть об этой болезни как о страшном сне?
Для уровня приложений у я использовал инструмент, который универсален для любой таблицы, но любая универсальность — это более сложная логика работы.
В триггере что я написал, подставляешь названия таблиц свои, названия полей, применяешь и забываешь.
Не представляешь как удобно теперь с таким деревом в консольке работать.
Этим решениям этим летом исполнилось 4 года. (http://phoinix.ucoz.ru/publ/7)
Сейчас мне захотелось их развить.
Тем более что 4 года назад триггеров в MySQL не было, как и хранимых процедур. Были только зачатки в 4-й не особо стабильной версии.
Немного не понимаю какое ограничение может наложить использование триггеров написаных на Java.
Не вижу никаких сложностей. doc.prototypes.ru/database/nestedsets/theory/
Есть определенная последовательность действий, которую я отработал еще 4 года назад.
А на каком уровне это реализовать и с помощью какого языка — вопрос исключительно религии разработчика ;-).
1. Короче не будет, понятнее будет еще меньше. Как раз цель в данном случае убрать вообще все непонятные действия с глаз долой, и работать без них.
2. Для Java решения нет, т.к. с ней не работал и надобности не было. Но есть решения для других языков:
Решение для Perl — phoinix.ucoz.ru/publ/5
Решение для PHP — phoinix.ucoz.ru/publ/6 (правда не до конца дописано, ввиду практической не надобности мне);
Была, конечно идея сделать модули не как додлнительный внешний инструментарий, а как встраиваемый, как прослойка интерфейсов («оберток») для работы с БД. Но таких «оберток» много больше и для каждой обертки делать решение — мягко скажем не рационально, а вот типов БД не так много, поэтому, ИМХО лучше эти вопросы решать на более низком уровне.
На выборках работает быстро.
+ еще достаточно много ништяков дополнительных, например количество узлов детей, родителей, всего в дереве получается безо всяких COUNT и дополнительные запросы нужны редко.
Основная грабля — это, конечно, изменение структуры дерева, собственно, данная статья как раз и облегчает эту работу. Но обновление идет по INTEGER полям, тесты не показали особых задержек.
А с учетом того, что на порядок чаще все-таки выборка, а не изменение, выигрыш существенный.
Комментарии скрыты, т.к. спама там сыпалось очень много, устал каждый день чистить.
Примеры SQL, да, возможно ошибки есть (особенно в теоретической статье), т.к. там лежат статьи еще первой редакции.
Давно чисткой не занимался. Как-то не до этого было.
Статьи новой редакции есть, но еще не выкладывал.
Зачищу, выложу.
Если честно, то на модуль HTTP::Request::Common я обратил внимание в первую очередь, когда стала такая задача.
Но увы, в процессе работы с ним столкнулся с некоторыми его багами и недочетами, в общем, мне лично, этот модуль не понравился, а самое главное он не отвечал главным требованиям задачи.
На самом деле изначально мне нужно было проксировать POST запросы со вложенными файлами, слегка модифицировав контент. Поэтому файлов, как таковых, у меня не было, а были объекты Apache::Upload.
Не вижу связи между пробегом по таблице и ORDER BY RAND()
EXPLAIN ничего интересного и не даст в данном случае.
И что примечательно, выборка по индексу у меня прошла в 2 раза медленней чем без него.
ORDER BY RAND() — зло по определению, и придумывать финты ушами можно бесконечно.
Проще от него отказаться.
Готовый пример случайного offset на чистом SQL:
SET @limit := 10;
SET @r := (SELECT COUNT(*) FROM test);
SET @offset := CEILING(RAND() * @r) — @limit;
SET @sql := CONCAT('SELECT * FROM test LIMIT ', @limit, ' OFFSET ', @offset);
PREPARE stmt1 FROM @sql;
EXECUTE stmt1;
При работе с несколькими языками программирования — то же самое.
Еще раз повторюсь.
Я до недавнего времени использовал подобные классы как плагины, но я посчитал, что перевод этого алгоритма на более низкий уровень более оправдано, ввиду использования в работе новых технологий.
Без комментариев.
PostgreSQL — тут не при чем, статья по нему по соседству.
ltree — не самое лучшее решение, особенно в части переноса веток, и подсчета.
Большую часть кода триггер вычисляет координаты, т.к. решение смешанное, то в качестве конечной координаты может быть parent_id, как в рекурсивных деревьях, так и left_key для деревьев Nested Sets. Отсюда немного усложненная логика вычисления координат.
При известных координатах вообще-то достаточно двух запросов для каждого из действий. Причем для перемещения, реально выполняется только один запрос обновления, а два их только потому, что они разные для направления перемещения.
Для уровня приложений у я использовал инструмент, который универсален для любой таблицы, но любая универсальность — это более сложная логика работы.
В триггере что я написал, подставляешь названия таблиц свои, названия полей, применяешь и забываешь.
Не представляешь как удобно теперь с таким деревом в консольке работать.
Сейчас мне захотелось их развить.
Тем более что 4 года назад триггеров в MySQL не было, как и хранимых процедур. Были только зачатки в 4-й не особо стабильной версии.
Не вижу никаких сложностей.
doc.prototypes.ru/database/nestedsets/theory/
Есть определенная последовательность действий, которую я отработал еще 4 года назад.
А на каком уровне это реализовать и с помощью какого языка — вопрос исключительно религии разработчика ;-).
2. Для Java решения нет, т.к. с ней не работал и надобности не было. Но есть решения для других языков:
Решение для Perl — phoinix.ucoz.ru/publ/5
Решение для PHP — phoinix.ucoz.ru/publ/6 (правда не до конца дописано, ввиду практической не надобности мне);
Была, конечно идея сделать модули не как додлнительный внешний инструментарий, а как встраиваемый, как прослойка интерфейсов («оберток») для работы с БД. Но таких «оберток» много больше и для каждой обертки делать решение — мягко скажем не рационально, а вот типов БД не так много, поэтому, ИМХО лучше эти вопросы решать на более низком уровне.
+ еще достаточно много ништяков дополнительных, например количество узлов детей, родителей, всего в дереве получается безо всяких COUNT и дополнительные запросы нужны редко.
Основная грабля — это, конечно, изменение структуры дерева, собственно, данная статья как раз и облегчает эту работу. Но обновление идет по INTEGER полям, тесты не показали особых задержек.
А с учетом того, что на порядок чаще все-таки выборка, а не изменение, выигрыш существенный.
Примеры SQL, да, возможно ошибки есть (особенно в теоретической статье), т.к. там лежат статьи еще первой редакции.
Давно чисткой не занимался. Как-то не до этого было.
Статьи новой редакции есть, но еще не выкладывал.
Зачищу, выложу.
Я тут можно сказать — новенький.
Решение вообще по Nested Sets — давно это было… не помню… с неделю может быть.
phoinix.ucoz.ru/publ/7
Модифицированы будут только работа с переменными и команды создания триггеров.
Но увы, в процессе работы с ним столкнулся с некоторыми его багами и недочетами, в общем, мне лично, этот модуль не понравился, а самое главное он не отвечал главным требованиям задачи.
На самом деле изначально мне нужно было проксировать POST запросы со вложенными файлами, слегка модифицировав контент. Поэтому файлов, как таковых, у меня не было, а были объекты Apache::Upload.
EXPLAIN ничего интересного и не даст в данном случае.
И что примечательно, выборка по индексу у меня прошла в 2 раза медленней чем без него.
Проще от него отказаться.
Готовый пример случайного offset на чистом SQL:
SET @limit := 10;
SET @r := (SELECT COUNT(*) FROM test);
SET @offset := CEILING(RAND() * @r) — @limit;
SET @sql := CONCAT('SELECT * FROM test LIMIT ', @limit, ' OFFSET ', @offset);
PREPARE stmt1 FROM @sql;
EXECUTE stmt1;
Ждем когда пирожки нахалявку можно будет покушать на поминках?