|
MySQL.RU - Webboard
 Вернуться
 иерархическое меню (bit) 30/04/2004 - 12:57:27
 Re: иерархическое меню (dEp) 30/04/2004 - 17:02:39
Re: Что за чушь?! (Sam) 02/05/2004 - 01:14:53
Re: Адрес (Sam) 02/05/2004 - 01:17:51
Re: Сам ты "чушь"?! (dEp) 03/05/2004 - 11:56:53
Re: Чушь! Однозначно. Доказателсьво внутри (Sam) 05/05/2004 - 21:54:14
Re: Re: а вот и не Чушь! (evg) 22/11/2006 - 14:33:09
> Original message text:
> From: bit - 30/04/2004 - 12:57:27
> Subject:иерархическое меню
> -----------------
> подскажите какую составить таблицу(-ы) для реализации иерархического меню?
> т.е :
> 1
> 1.1
> 1.1.1
> 1.2
> 2
> и т.д.
>
From: Sam - 02/05/2004 - 01:14:53
Subject:Что за чушь?!
-----------------
Дип, ты что, прикалываешься?!
Как например пункт 1.2.1 в твою таблицу внести?
Есть только два более или менее удачных решения.
1 - использовать в качестве идентификатора специальным образом сформированный номер. Например так. Идентификатор - 32 битное целое. По 8 бит на нумерацию пунктов в пределах одного раздела для 2-го, 3-го и 4-го уровней. 7 бит на нумерацию пунктов в корне дерева. (7 бит для того чтобы избежать отрицательных номеров разделов)
Тогда твои пункты могут нумероваться так:
0x01000000 - 1
0x01010000 - 1.1
0x01010100 - 1.1.1
0x01020000 - 1.2
0x02000000 - 2
Достоинство этого метода: очень удобно выбирать ветки деревьев, легко определять уровень и родителей.
Например все потомки пункта 1.5:
WHERE id > 0x01050000 AND id < 0x01060000
Или номер самого первого предка текущего элемента:
id & 0xFF000000
Недостатки - нумеровать можно только пункты от 0.0.0.0 до 127.255.255.255. Максимум 4 уровня вложенности, максимум 127 пунктов в корневом разделе, максимум 255 пунктов в любом другом разделе.
2 - второй подход. Использовать ссылку родительский элемент.
то есть в таблице храним два поля id и pid - id первичный ключ, pid - внешний ключ на свое же поле id.
Достоинства - можно хранить любое дерево, с любым колличеством пунктов, сколько угодно уровней вложенности. (кроме того структура понятная и простая)
Недостатки: сложно выбирать поддеревья, нужно использовать рекурсивную процедуру, и ней будет столько раз вызываться SELECT из базы, сколько пунктов выберешь. Если база данных не поддерживает каскадное удаление, то при удалении ветки придется на каждый узел вызывать select, на на каждый элемент DELETE. А поскольку удаляя нужно сначала удалять самые последние потомки (листья), то рекурсивная процедура будет интенсивно использовать стек.
Я использую симбиоз этих двух методов.
Храню деревья в таблице с id и pid, но при каждом изменении генерирую кэширующую таблицу c полями
ndx, pndx, id, pid. И при выборке получаю такую же скорость работы как для первого метода, но без его ограничений.
Если не ясно - обращайся в письме - подскажу.
[Это сообщение - спам!]
Последние сообщения из форума
Уважаемые посетители форума MySQL.RU!
Убедительная просьба, прежде чем задавать свой вопрос в этом форуме, обратите внимание на разделы:
- ответы на наиболее часто задаваемые вопросы - FAQ
- раздел документация
- раздел поиск по сообщениям форума и документации
Также, старайтесь наиболее подробно указывать свою ситуацию (версию операционной системы, версию MySQL,
версию программного обеспечения, по которому возникает вопрос, текст возникающих ошибок, и др.)
Помните, чем конкретнее Вы опишете ситуацию, тем больше шансов получить реальную помощь.
30157
|
|
