И снова деревья / PostgreSQL

ReSQL.ru

Мобильная версия Контакт Правила FAQ Помощь

Гость

Войти | Регистрация | Профиль | Очистить

Новые сообщения | Избранное

Форумы | Пользователи | Статистика | Мод. лог | Поиск

Цитировать

Написать

Автор*:

Ввести пароль для входа

Тема*:

Сообщение

Данное сообщение тематическое

Сообщение содержит картинки или видео 18+

Автор:

ВНИМАНИЕ! На данном подфоруме действуют строгие правила. Удостоверьтесь, что ваше сообщение соответствует им!

Форум или тема закрыты для гостей. Необходима авторизация!

Загрузить последнюю сохраненную версию

Вложение:

Вставить как галерею

Максимальный размер вложений: 4,0 МБ, аудио/видео: 8,0 МБ. Картинки большего размера ужимаются, если возможно.

Введите код, изображенный на картинке. Если код нечитаемый, кликните картинку, чтобы загрузить другой вариант.

Отправляя сообщение, я выражаю свое согласие с правилами форума и принимаю пользовательское соглашение.

Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр

Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / И снова деревья

7 сообщений из 7, страница 1 из 1

И снова деревья

#35124811

raul_83

Гость

версия постгресса - 8.2.5. Какие способы хранения и отображения деревьев?

Насколько надежно и быстро работает (и работает ли вообще) CONNECT BY PRIOR, и как его "доставить"?

Спасибо

...

Рейтинг:

0 / 0

11.02.2008, 16:59

| Ответить | Цитировать | Написать

И снова деревья

#35125424

Oleg Bartunov

Участник

Сообщения: 220

Рейтинг: 0 / 0

raul_83версия постгресса - 8.2.5. Какие способы хранения и отображения деревьев?

Насколько надежно и быстро работает (и работает ли вообще) CONNECT BY PRIOR, и как его "доставить"?

Спасибо

а ты смотрел contrib/ltree ?

...

Рейтинг:

0 / 0

11.02.2008, 22:11

| Ответить | Цитировать | Написать

И снова деревья

#35125555

aov

Участник

Откуда: Украина

Сообщения: 266

Рейтинг: 0 / 0

о! а я токо хотел про ето поболтать :)
вот есть потребность в иерархичности справочников в проге моей - но пока не необходимость :).
полистал немного форумы и т.п. - мало что понял :).
ну и вот я для прикола провёл следственный эксперимент. сразу если кому это покажется смешно - пожалуйста - я не обижусь :). просто меня почемуто это удивило - я думал так не получится. теперь то получилось - токо теперь я не понимаю почему так делать не хотят... ну вот собственно сам эксперимент:

Код: plaintext

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.

create schema tree;
comment on schema tree is 'тестирование деревообразновидных справочников :)';
create table tree.spr(
id serial primary key,
fk_parent int,
spr text unique not null,
descr text,
constraint parent_fkey foreign key(fk_parent) references tree.spr on update cascade on delete cascade
);
--корневые ветки:
insert into tree.spr(spr,fk_parent) 
values('root1',null),
('root2',null);
--ветвимся дальше:
insert into tree.spr(spr,fk_parent) 
values('root1.child1', 1 ),
('root1.child2', 1 );
--ещё дальше:
insert into tree.spr(spr,fk_parent) values('root1.child1.child1', 3 );
--каскадное удаление - фунциклирует - как ни странно :) - осталась токо строка с ид=2...:
delete from tree.spr where id= 1 ;

--теперь то же самое - токо вместо cascade будет restrict:
alter table tree.spr drop constraint parent_fkey;
alter table tree.spr add constraint parent_fkey foreign key(fk_parent) references tree.spr on update cascade on delete restrict;

--корневые ветки:
insert into tree.spr(spr,fk_parent) 
values('root3',null);
--ветвимся дальше:
insert into tree.spr(spr,fk_parent) 
values('root2.child1', 2 ),
('root2.child2', 2 );
--ещё дальше:
insert into tree.spr(spr,fk_parent) values('root2.child2.child1', 2 );
--удаляем корешок:
delete from tree.spr where id= 2 ;
/*ERROR:  update or delete on table "spr" violates foreign key constraint "parent_fkey" on table "spr"
DETAIL:  Key (id)=(2) is still referenced from table "spr"*/

а народ изобретает какие-то геморные велосипеды на эту тему... странно. вот же ш вам пожалуйста на блюдечке - вставка, перемещение, удаление ветки со всеми ответвлениями. единственную вижу проблему - это всякие выборки по типу с сортировкой по алфавиту в пределах ветки всего дерева, полный путь и тому подобное. ну это совсем не сложно на plpgsql сделать - у самого пока руки не доходили - но думаю пара циклов - и рекурсия наверное... скорее всего... токо на plpgsql никогда её не пользовал - не знаю можно ли :) - можно? надо попробовать... токо видимо со скоростью не супер будет - но я думаю вполне терпимо должно быть - целостность данных важнее адназначна! на крайняк если совсем уж сильные пробуксовки будут можно вообще отказаться от загрузки всего дерева целиком - грузить токо раскрываемую пользователем ветку. т.е. подгружать узлы по мере требования. думаю тоже нормально будет. может и вообще сразу так сделать - ещё не решил.

что скажете? какие тут возможны грабли?

...

Рейтинг:

0 / 0

12.02.2008, 02:34

| Ответить | Цитировать | Написать

И снова деревья

#35125684

Kruchinin Pahan

Участник

Откуда: Екатеринбург

Сообщения: 926

Рейтинг: 0 / 0

aovа народ изобретает какие-то геморные велосипеды на эту тему... странно. вот же ш вам пожалуйста на блюдечке - вставка, перемещение, удаление ветки со всеми ответвлениями. единственную вижу проблему - это всякие выборки по типу с сортировкой по алфавиту в пределах ветки всего дерева, полный путь и тому подобное. ну это совсем не сложно на plpgsql сделать - у самого пока руки не доходили - но думаю пара циклов - и рекурсия наверное... скорее всего... токо на plpgsql никогда её не пользовал - не знаю можно ли :) - можно? надо попробовать... токо видимо со скоростью не супер будет - но я думаю вполне терпимо должно быть - целостность данных важнее адназначна! на крайняк если совсем уж сильные пробуксовки будут можно вообще отказаться от загрузки всего дерева целиком - грузить токо раскрываемую пользователем ветку. т.е. подгружать узлы по мере требования. думаю тоже нормально будет. может и вообще сразу так сделать - ещё не решил.

что скажете? какие тут возможны грабли?
Это классическое SQL дерево. Нормальная схема, прекрасно работает. Но, тормоз. Если в дереве 20-80 тыс записей, то работа непосредственно с самим деревом не тормозит. А вот когда тебе надо выбрать все узлы из какой-то одной ветки и пересечь результат с таблицей-милионником, вот здесь начинается швах. Поэтому приходится на такие деревья навешивать костыли.

...

Рейтинг:

0 / 0

12.02.2008, 08:07

| Ответить | Цитировать | Написать

И снова деревья

#35125892

aov

Участник

Откуда: Украина

Сообщения: 266

Рейтинг: 0 / 0

а - ну у меня думаю ни 20тыс записей в дереве ни пересечения с милионами с других таблиц никогда не будет :) - у меня пока это нужно токо для групп товаров. думаю их никогда не будет более 1000 - а по среднему 20-200. и самих товаров - для пересечения - 7-10тыс - ну максимум 30 - при любом раскладе на любого срока перспективу. тоесть получается вроде как мне - по крайней мере для этой задачи - нет смысла заморачиваться? этого хватит?
а что меня вообще удивило и почему - у меня кроме постгреса токо с аксесом плотное знакомство было :) - там кажися не было возможности поддержки целостности данных при такого типа связей. хотя... - может это я балбес :). не помню пробовал ли... уже не оч помню почему - но результаты эксперимента с условиями на целостность данных меня оч удивили. уж и не знаю почему я решил что не будет работать :)

...

Рейтинг:

0 / 0

12.02.2008, 10:07

| Ответить | Цитировать | Написать

И снова деревья

#35126103

raul_83

Гость

Oleg Bartunov raul_83версия постгресса - 8.2.5. Какие способы хранения и отображения деревьев?

Насколько надежно и быстро работает (и работает ли вообще) CONNECT BY PRIOR, и как его "доставить"?

Спасибо

а ты смотрел contrib/ltree ?

Смотрел connectby, возвращает иерархию, то что нужно. На сколько стабильно и быстро осуществляется выборка? Есть ли смысл использовать классическое представление деревьев, триггером заполнять необходимые поля. Понятно, что в классическом виде увеличится скорость выборки, но замедлится процесс добавления, изменения записей.
Таблица - несколько сот тысяч записей, в перспективе - больше, уровень вложенности - ну пусть будет до 20 (перестраховываюсь).

...

Рейтинг:

0 / 0

12.02.2008, 11:02

| Ответить | Цитировать | Написать

И снова деревья

#35126912

MBG

Гость

raul_83
Таблица - несколько сот тысяч записей, в перспективе - больше, уровень вложенности - ну пусть будет до 20 (перестраховываюсь).

Если данных планируется много, лучше сделать набор функций, которые для каждого уровня будут создавать отдельные таблицы. В этом случае планировщик сможет эффективно обрабатывать связку этих таблиц с другими (независимо от высоты дерева). Иначе при попытке привязать к таблице-дереву десяток больших таблиц (миллионы записей и более) будет полный ахтунг. В общем-то, построить дерево можно многими путями, вопрос в том, что для эффективной работы с такой структурой ее строение должен "понимать" постгрес, иначе sql-запросы станут неэффективны. Так что если описывать дерево, то в терминах реляционной модели, иначе просто нет смысла (если данных мало, можно делать как больше нравится, например, хранить все дерево в виде массива и т.п.).

...

Рейтинг:

0 / 0

12.02.2008, 13:55

| Ответить | Цитировать | Написать

7 сообщений из 7, страница 1 из 1

Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / И снова деревья

Читали тему (0):

Читали форум (0):

Пользователи онлайн (0):

start [/forum/topic.php?fid=53&msg=35126103&tid=2004619]:	0ms
get settings:	9ms
get forum list:	10ms
check forum access:	3ms
check topic access:	3ms
track hit:	148ms
get topic data:	8ms
get forum data:	2ms
get page messages:	35ms
get tp. blocked users:	1ms
others:	242ms

total:	461ms