Деревья

← →
Zhouck © (2003-09-16 11:16) [0]

Такой вот метод создания иерархии - кроме ID создаем поля Level и Hash. В хэше первого уровня - 001,002,003...,999. В хэше второго уровня 001001,001002,...,001999,...,999001,999002,...999999, что в хэшах третьего , думаю всем ясно. Хэш лучше делать типа char(255) влезет все. Какие недостатки у данного метода ?

← →
Nikolay M. © (2003-09-16 11:23) [1]

> Какие недостатки у данного метода ?

Поддерживает не более 999 веток из одной вершины, расход памяти под кучу полей char(255), причем хэш каждой ветки будет занимать именно 255 байт, т.к. выбран тип char.
Плюс будет возня при удалении/добавлении новых ветвей(листьев) - придется придумывать алгоритм назначения нового хэша и вообще, имхо, геморрой не стоит свеч...

← →
Zhouck © (2003-09-16 11:29) [2]

Ну то что 999 , это не проблема, можно и 999999. Можно и varchar
, тогда редко какой будет 255. Зато - найти всех потомков некоторого родителя можно без рекурсии, а так как есть уровни - то и с группировкой. Гемор будет на DDL , но не будет его на DML

← →
pasha_golub © (2003-09-16 12:11) [3]

Я вообще-то придерживаюсь классического подхода, то есть список списков.

← →
Nikolay M. © (2003-09-16 13:08) [4]

> Зато - найти всех потомков некоторого родителя можно без
> рекурсии, а так как есть уровни - то и с группировкой.

В классике для нахождения потомков тоже можно обойтись без рекурсии (имхо, ее лучше вообще не использовать, незачем стек засорять).
И чем пугает нахождение потомков по классике? А тут пахнет некислым расходом памяти и вообще...

← →
AlexVM © (2003-09-16 13:13) [5]

Посмотри www.codenet.ru/db/trees/ - может поможет...

← →
Zhouck © (2003-09-16 13:41) [6]

Ха , а как вам нахождение всего поддерева -
select * from tree where hash like "001%"? Где проще ?

← →
NAlexey © (2003-09-16 13:47) [7]

Судя по всему автор уже давно решил что его метод самый лучший. Не так ли?

← →
Zhouck © (2003-09-16 13:54) [8]

Совсем нет. Я этот метод придумал 3 часа назад и еще даже и не реализовывал.

← →
Nikolay M. © (2003-09-16 14:09) [9]

Ну, если решишь-таки реализовывать, делай тогда хэш не "001002003", а "1,2,3". Опять же SELECT ... WHERE ID IN (:hash) проще сделать. Мы так делали на вебе для MySQL, где важна была скорость и информация изменялась целиком, но для постоянной работы c деревом я бы такой вариант не принял.

← →
Zhouck © (2003-09-16 14:27) [10]

За совет - спасибо. А почему для постоянной работы вариант не подходит? И скорость, и надежность есть. Нужно просто много триггеров написать, но зато работать из дальше будет проще

Нет ли у кого нибудь других соображений на эту тему , деревья
ведь по разному можно реализовывать...

тебя какая задача-то волнует ?
уникальность имен узлов или быстрая выборка узлов указанного поддерева ?

первое - в ряде случаев подойдет обычное CRC32/64
второе - к основной "деревянной" таблице создается вспом.таблица реляций вида
Id - Name - Level - ParentId - RootId, модифицируемая астоматически в теле соотв.триггеров

Задача приблизительно такова:
Есть отделы, сотрудники (иерархия на предприятии думаю всем ясна)
Нужно получать любые поддеревья (департамент,отдел,группа etc)
и иметь возможность группировки по количеству зарплаты, отработанных дней, коммандировок etc

Деревья Найти похожие ветки