PHP.SU

Программирование на PHP, MySQL и другие веб-технологии

PHP.SU Портал

Главная

Помощь

Поиск

Поиск Яндекс Вакансии

Пользователи

Здравствуйте, Гость

( Вход · Регистрация · Правила форума )

Забыли пароль?

построение "хлебных крошек" одним запросом

Форумы портала PHP.SU » PHP » SQL и Архитектура БД (Модератор: SAD)

Страниц (2): « 1 [2]

Описание: все дерево в одной таблице

Поиск в теме | Версия для печати

tuareg	Отправлено: 17 Декабря, 2011 - 01:36:57
Участник Покинул форум Сообщений всего: 1234 Дата рег-ции: Июнь 2010 Помог: 69 раз(а)	DlTA пишет: tuareg пишет: Да не ну это глупо, зачем??? MySql не для этого не для чего? Зачем пытаться "забить гвоздь микроскопом"? Вам нужна иерархия есть решения. Евген предложил не плохой вариант.(Кстати наверное оптимальный) Вы знаете сколько у вложений(есть ограничение)?

Champion	Отправлено: 17 Декабря, 2011 - 09:09:59
Активный участник Покинул форум Сообщений всего: 4350 Дата рег-ции: Авг. 2008 Откуда: Москва Помог: 57 раз(а)	EuGen пишет: И в чем разница? Рекурсивная процедура ничуть не лучше рекурсии на php. Речь не о рекурсивной процедуре, а о рекурсивном запросе. Но и рекурсивная процедура будет лучше кода на php, потому что в случае кода на php будет послали данные - получили - послали - получили (query-fetch-query-fetch). EuGen пишет: 50 JOIN - плохо, если данных действительно много. Нуу не факт. Они не будут тяжелее того же рекурсивного CTE или рекусривной процедуры на стороне СУБД. Там ведь у первой таблицы берется одна строка, и каждая следующая таблица приджойнивается по первичному ключу. И потом все 50 джойнов не будут выполняться. Когда мускуль в очередном джойне не найдет данных, ему уже нечего будет джойнить. Хотя я призадумался, поймет ли он это. Надо поэксперементировать. Заодно и скорость рекурсивной процедуры посмотрю) EuGen пишет: То, что я предлагал с полным путем - вряд ли изящно тоже, так как в случае перемещения узла где-нибудь в середине пути будет очень много запросов на поиск и обновление (по сути обновить нужно будет все нижележащие поддеревья). Но всё-таки, по-моему, это редкое явление - перемещение узла, так что эту затрату можно не считать большим минусом.

DlTA	Отправлено: 17 Декабря, 2011 - 09:25:58
Постоянный участник Покинул форум Сообщений всего: 2952 Дата рег-ции: Окт. 2010 Помог: 53 раз(а)	tuareg пишет: Зачем пытаться "забить гвоздь микроскопом"? Вам нужна иерархия есть решения. Евген предложил не плохой вариант.(Кстати наверное оптимальный) Вы знаете сколько у вложений(есть ограничение)? чет я так и не понял во что меня пытаются ткнуть?! то что реализуется через костыли, понятно, какой костыль выбрать примерно тоже понятно, особенно с учетом дополнительных условий (при скрытии одного узнал должны быть скрыты и не доступны для поиска злы идущие дальше)

tuareg	Отправлено: 17 Декабря, 2011 - 13:59:52
Участник Покинул форум Сообщений всего: 1234 Дата рег-ции: Июнь 2010 Помог: 69 раз(а)	Сегодня глянул. Если Вы знаете сколько вложений CODE (SQL): скопировать код в буфер обмена SELECT t1.`id`,t2.`id`,t3.`id`,t4.`id` FROM `new_table` AS t1 LEFT JOIN `new_table` AS t2 ON t1.`id`=t2.`parent` LEFT JOIN `new_table` AS t3 ON t2.`id`=t3.`parent` LEFT JOIN `new_table` AS t4 ON t3.`id`=t4.`parent` WHERE t1.`id`=1; Результат: Родитель->вложение-->вложение--->вложение Это один запрос получится, но джойнить он будет таблицу 3 раза, не оптимально это. Все-таки посмотрите в сторону процедур или хотя бы подготовленных выражений (Отредактировано автором: 17 Декабря, 2011 - 14:29:26)

DlTA	Отправлено: 17 Декабря, 2011 - 16:26:56
Постоянный участник Покинул форум Сообщений всего: 2952 Дата рег-ции: Окт. 2010 Помог: 53 раз(а)	tuareg пишет: Результат: Родитель->вложение-->вложение--->вложение Это один запрос получится, но джойнить он будет таблицу 3 раза, не оптимально это. Все-таки посмотрите в сторону процедур или хотя бы подготовленных выражений читали примеры на предыдущей странице?

Поиск в теме | Версия для печати

Страниц (2): « 1 [2]

Сейчас эту тему просматривают: 0 (гостей: 0, зарегистрированных: 0)

« SQL и Архитектура БД »

Все гости форума могут просматривать этот раздел.
Только зарегистрированные пользователи могут создавать новые темы в этом разделе.
Только зарегистрированные пользователи могут отвечать на сообщения в этом разделе.