можно ли эту прикольноСТЬ в запросах select использовать, а не гонять рекурсию, теряЯ время выполнения?
Подзапросы тебе помогут. Только не забывай, что возвращается в любом случае обычная прямоугольная таблица с данными, а не дерево, так что настоящая рекурсия тут вряд ли возможна.
Всмысле подзапросы?.. у меня рекурсия: функция которая вызывает id родителя и передаёт его ещё раз в саму себя - это возврат, он не проблема, выполняется быстро, т. к. запросов мало получается... а если например дерево построено на одной таблице, и к каждой конечной ветке прикреплены элементы из другой таблицы а к этим элемента ещё из других таблиц элементы... вот например устроено faq... директории в одной таблице, в конечной директории сами статьи в отдельной таблице, а в статьях есть файлы, которые тоже в отдельной таблице... чтобы всё это удалить, с помощью FOREIGN KEY - нет проблем, быстро и эффективно, а если нужно вывести имена файлов, чтобы удалить их, а после уже удалить записи в БД?.. Тут уже рекурсия, она получается длинная... pconnect немного спасает, время экономит, но всёже медленно... Есть более практичное решение?
что именно надо удалять так часто? надо копать задачу и структуру базы. можно тупо хранить старшего прародителя.
нужно из вышеперечисленного удалить файлы по их именам, а имена нужно вытащить из всего дерева... я и создал тему т. к. не хочу хранить путь до родителя...
удалить файлы, удалить их заголовки в таблице с деревом, в случае пустых листьев удалить листья? или как? и как часто это надо делать? "имена из всего дерева" вытаскиваются без его обхода.
тут дело не в самом удалении, нужно вытащить имена файлов... - нужно делать это очень часто "имена из всего дерева" вытаскиваются без его обхода. - это только если хранить путь
хмм. все равно странная структура. что-то на такую тему: PHP: mysql_query("set @P:=$id4del"); mysql_query("set @K:=$id4del"); mysql_query("select *, @K:=@P, @P:=dirs.d_parent_id from dirs, files where files.f_dir_id=dirs.d_id and d_id=@K");