Моделирование иерархических объектов
От: Аноним Сергей Виноградов  
Дата: 13.06.03 03:21
Оценка: 35 (3)
Статья :
Моделирование иерархических объектов

Авторы :
Сергей Виноградов



29.06.03 02:09: Перенесено модератором из 'Алгоритмы' — _MM_
Плюсы изложены.. А вот минусы:
От: Аноним  
Дата: 21.12.01 23:47
Оценка:
Неплохое изложение статей Celko. Было бы, прада, лучше, если бы это был полный перевод.
Насчет минусов этой схемы хранения данных:
при самых маленьких изменениях — добавлении узла, удалении узла, перемещении ветки — необходимо изменить в среднем ПОЛОВИНУ ВСЕХ ЗАПИСЕЙ.
=> Очень неудобно для систем с репликацией данных
=> Очень нехорошо для версионных БД — плодятся версии
=> Очень неэффективная схема для больших деревьев с изменениями.
Представь — в дереве миллоион узлов. Ты добавляешь ОДИН и должен изменить 500 000.
Круто?
По поводу функциональности
От: Аноним  
Дата: 17.11.01 22:39
Оценка:
Самое интересное, что в этих статьях про деревья практически никогда не рассматироваются такие вопросы как

Ну да ладно.
Re: Плюсы изложены.. А вот минусы:
От: Аноним  
Дата: 06.03.02 04:48
Оценка:
А кстати, я видел полный перевод перевод этих статей.

http://sdm.viptop.ru/articles/sqltrees.html
Re: Плюсы изложены.. А вот минусы:
От: Sergey Vinogradov Россия  
Дата: 10.01.02 19:12
Оценка:
Очень невнимательно читаете — об этом же написано:
"Главный недостаток этого решения в том, что при изменении в структуре дерева, приходится заново пересчитывать значения полей Left и Right во всей таблице. То есть, такой способ годится только для небольших, редко изменяемых таблиц."

Поэтому и предлагается второй способ — со вспомогательной таблицей.
Re: Моделирование иерархических объектов
От: Jericho113 Украина  
Дата: 09.10.06 14:23
Оценка:
Здравствуйте, Сергей Виноградов, Вы писали:

СВ>Статья :

СВ>Моделирование иерархических объектов

СВ>Авторы :

СВ>Сергей Виноградов


Может я сильно туплю но поясните мне неучу в статье в таблице Departments узел B1 имеет [left=2 right=4]
НО почему узел лежащий НИЖЕ его — С1 имеет [left=3(это понятно) НО right=3 ????? ] ведь при обходе дерева если у его предка В1 right=4
то опускаясь ниже по правой стороне дерева получим у С1 rigth = 5.

Может я просто слегка туплю но почему так???
NetDigitally yours ....
Re[2]: Моделирование иерархических объектов
От: Ромашка Украина  
Дата: 09.10.06 14:50
Оценка:
Jericho113 пишет:
> Может я сильно туплю но поясните мне неучу в статье в таблице
> Departments узел B1 имеет [left=2 right=4]
> НО почему узел лежащий НИЖЕ его — С1 имеет [left=3(это понятно) НО
> right=3 ????? ] ведь при обходе дерева если у его предка В1 right=4
> то опускаясь ниже по правой стороне дерева получим у С1 rigth = 5.

Вообще-то в статье не совсем правильно. Насколько помню Celko, B1 должно
быть [left=2 right=5], у C1 должно быть [left=3 right=4].

> Может я просто слегка туплю но почему так???


Не обьяснен смысл, потому что. Множество C1 вложено в множество B1,
сответственно, границы множества C1 должны быть внутри границ B1.
Собственно, найди Joe Celko (слова для поиска -- nested sets) и почитай
в оригинале.

ЗЫ. Автор, кстати, неправ по поводу "Главный недостаток этого решения в
том, что при изменении в структуре дерева, приходится заново
пересчитывать значения полей Left и Right во всей таблице. То есть,
такой способ годится только для небольших, редко изменяемых таблиц."
Posted via RSDN NNTP Server 2.0


Всё, что нас не убивает, ещё горько об этом пожалеет.
Re[3]: Моделирование иерархических объектов
От: Jericho113 Украина  
Дата: 09.10.06 15:06
Оценка:
Здравствуйте, Ромашка, Вы писали:


Р>Вообще-то в статье не совсем правильно. Насколько помню Celko, B1 должно

Р>быть [left=2 right=5], у C1 должно быть [left=3 right=4].
Именно так я понял но статья с толку сбила


Р>Не обьяснен смысл, потому что. Множество C1 вложено в множество B1,

Р>сответственно, границы множества C1 должны быть внутри границ B1.
Р>Собственно, найди Joe Celko (слова для поиска -- nested sets) и почитай
Р>в оригинале.

Да вот читал но потом почитал статью и был немного озадачен
странно что никто не заметил и/или не написал по этому поводу.

Р>ЗЫ. Автор, кстати, неправ по поводу "Главный недостаток этого решения в

Р>том, что при изменении в структуре дерева, приходится заново
Р>пересчитывать значения полей Left и Right во всей таблице. То есть,
Р>такой способ годится только для небольших, редко изменяемых таблиц."

Да вот хотелось бы спросить почему автор неправ?
Я планирую использовать этот метод хранения иерархии у себя, т.к.
есть список подразделений которые редко добавляются,
но часто по ним нужно быстро делать выборки
(
а)от заданного узла выбрать всех его потомков,
b)выбрать все узлы которые находятся на одном заданном уровне
)
и желательно что бы эти выборки были очень быстрыми.

Вот пока выбираю и присматриваюсь...
NetDigitally yours ....
Re[4]: Моделирование иерархических объектов
От: Ромашка Украина  
Дата: 10.10.06 06:28
Оценка:
Jericho113 пишет:
> Р>ЗЫ. Автор, кстати, неправ по поводу "Главный недостаток этого решения в
> Р>том, что при изменении в структуре дерева, приходится заново
> Р>пересчитывать значения полей Left и Right во всей таблице. То есть,
> Р>такой способ годится только для небольших, редко изменяемых таблиц."
>
> Да вот хотелось бы спросить почему автор неправ?

Идея вроде fill factor в индексах. То есть получится что-то вроде
B1[left=2000 right=5000], C1[left=3000 right=4000]. Потом при изменениях
просто пользуешься свободными диапазонами. Реализацию где-то в инете для
интербейза видел.

> Вот пока выбираю и присматриваюсь...


ИМХО, стоит выбирать либо из вложенных множеств, либо из транзитивного
замыкания. Впрочем, тема не раз обсуждалась на данном форуме.
Posted via RSDN NNTP Server 2.0


Всё, что нас не убивает, ещё горько об этом пожалеет.
Re[5]: Моделирование иерархических объектов
От: Igor Trofimov  
Дата: 10.10.06 17:05
Оценка:
Р>ИМХО, стоит выбирать либо из вложенных множеств, либо из транзитивного
Р>замыкания. Впрочем, тема не раз обсуждалась на данном форуме.

ИМХО. стоит выбирать изходя в первую очередь из задач и требований.