PEAR:DB_NestedSet кто-нибуть юзает?

[kvf77]

algo

а зачем применять Nested Sets для того, для чего оно не предназначено, например, для непочти статичных иерархий?

left и right вовсе не левые, это часть теории и методологии, таким образом ты можешь в отстой списать чуть ли не все теории на свете. чем реальные id удобнее для выборок - не знаю, я прекрасно и с left и right выбираю и никакого дискомфорта не испытываю.

что касается helper table - то подход очень избыточен и врядли намного эффективнее деревьев. что касается целостности - то боюсь ее гарантировать нельзя ни при каком подходе, пока жива артия обезьянок-умельцев, лезущих везде и всегда ручками - он тупого юзера ничто не спасет

 

[he][es]

algo если честно то не совсем понял тебя...
Соглашусь с kvf77

а зачем применять Nested Sets для того, для чего оно не предназначено, например, для непочти статичных иерархий?

Мне вот вполне нравится подход...

Пункты 1 и 2 могут не играть роли в конкретном приложении, но серьезно ограничивают применение подхода.

Точно так же можно сказать, а на РНР не пишут приложения... (не вэб) Так он и не для этого как бы делался...
(насколько я понимаю pid это id предка? Тогда супер афигенски удобный подход. Как выбрать ВСЕХ потомков элемента на 3 уровня вложенности одновременно выстроив их согласно "плану"? А никак... Поэтому при начале текущего проекта мы отказались от этого подхода.)
И вообще в топике о Nested Sets ваши посты несколько оффтопны...
А по поводу хранимых процедур что нить скажет уважаемая общественность? Ответ "Да нормал." конечно радует, но ...

 

[kvf77]

he][es
ну куда уж точнее - я ж сказал конкретно - если есть возможность хранимки делать НАДО ДЕЛАТЬ ИМЕННО НА НИХ - это обеспечивает более точную сохранность данных, высокую скорость их обработки и еще другие всякие преимущества

 

[he][es]

Ну я типа хотел предложить уважаемой общественности этим заняться (не в стиле "Эй вы там делайте" ) а может поделить работу на участников и написать эти процедуры... (типа PEAR свой... )

 

[crocodile2u]

Уважаемая общественность, точнее, та ее часть, которой приходилось использовать вложенные множества на СУБД, поддерживающих хранимые процедуры, уже написала свои решения Кстати: нет ничего сложного в том, чтобы перенести часть кода из DB_NEstedSet в хранимые процедуры...

 

[kvf77]

crocodile2u

Думается мне этот топик в пору в FAQ включать - любопытный получился

 

[algo]

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

he][es

(насколько я понимаю pid это id предка? Тогда супер афигенски удобный подход. Как выбрать ВСЕХ потомков элемента на 3 уровня вложенности одновременно выстроив их согласно "плану"? А никак... Поэтому при начале текущего проекта мы отказались от этого подхода.)

Такие выборки делаются легко. Вот, кстати, ссылка
http://www.osp.ru/os/2003/04/076.htm
Там и nested set и helper table.

 

[kvf77]

algo

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

 

[algo]

Избыточность данных не излишняя.. Она позволяет делать инсерты без апдейта на полтаблицы.
Очень удобно.

А то сейчас иерархия статическая, завтра она полустатическая.. Зачем перепроектировать иерархию? helper table и никаких гвоздей

Еще плюс helper table.. Выборки по всей иерархии идут через
WHERE pid=<..>. Это быстрее, чем поиск WHERE a BETWEEN b AND c.

P.S Все молчат по поводу ltree... Почему ??

 

[Sad Spirit]

Автор оригинала: he][es
Ну я типа хотел предложить уважаемой общественности этим заняться (не в стиле "Эй вы там делайте" ) а может поделить работу на участников и написать эти процедуры... (типа PEAR свой... )

У общественности, как правильно отметил crocodile2u, процедуры уже написаны.

algo
Ну в сообщении в livejournal предлагается эмуляция последовательностей через таблицу... К тому же товарищ недоговаривает: в PostgreSQL (о миграции народа с которого он явно и видит эротические сны) кроме nextval() есть ещё функция currval(), реализовать поведение которой на уровне ХП затруднительно...

 

[algo]

Sad Spirit

Вроде там все ок с этим как раз.. LAST_INSERT_ID() возвратит как раз этот самый currval.

Sad: ты тоже не юзаешь ltree ?

 

[Sad Spirit]

Автор оригинала: algo
ты тоже не юзаешь ltree ?

нет, у меня щас деревья используются только в контексте иерархии разделов сайта. изменяется эта иерархия нечасто, а всякие хитрые запросы на выборку нужны -> nested sets. Естественно, не обсуждаемая реализация, а хранимые процедуры.

 

[algo]

А есть какая-то причина, по которой ты предпочел Nested sets вместо ltree ?

 

[he][es]

У общественности, как правильно отметил crocodile2u, процедуры уже написаны.

Эх... Залошили У меня нету...
А уважаемая общественность не поделится?..
algoя эту статью смотрел. (не буду врать мельком) И не понял как там можно такие выборки сделать... (ну да ладно. хрен с ними...)

 

[kvf77]

algo

почитал про ltree - не подходит оно для проектов, кторые могут легко менять базу - она ж заточена под конкретные вещи. их можно использовать, если проект живет в PostgreSQL - ну а вдруг захотят MySql - этож какая запара переносить - меж тем, NestedSets всеже обладают изрядной долей мобильности, ровно как и Adjacency List

he][es
то как тока они устоятся в MySql, вы пущу версию класс своего для работы в виде хранимых процедур.

 

[crocodile2u]

kvf77
Эх, когда еще они устоятся в MySQL... Конечно, многое тогда придется переписывать (ну, или захочется переписать) - но дело того стоит. И, кстати: имхо, для подавляющего большинства проектов с применением хранимых процедур хорошо подойдут обычные Adjacency Lists для деревьев - ведь рекурсивные запросы уже не придется гонять туда-сюда между приложением и сервером БД. Хотя, конечно, если нагрузки высоки, придется искать свое - наиболее подходящее - решение для каждого случая...

 

[kvf77]

crocodile2u

ну я упоминал Nested Sets только в относительности с ltree

ну а что касается хранимок в Мускуле -посмотрим, они в общем-то быстро щас работают и довольно качественно (я имею ввиду вирму, а не хранимки)

 

[he][es]

С новым релизом популярной открытой СУБД MySQL — 5.0.13 — ветка 5.0 перешла в стадию кандидата в релизы (RC, Release Candidate).

Вот...

 

[kvf77]

he][es

я те по секрету скажу - она куда-либо перейдет тока когда я у своего хостера ее увижу

 

[he][es]

kvf77 ну... этого можно и года 2 ждать... А после того как она в релиз уйдёт, можно будет попробовать пнуть саппорт хостера, что бы поставили... (иногда помогает)...