Есть ли что-то похожаее на hierarchyid?

Какой-то аналог SQL Server типа hierarchyid?

Чтобы поддерживать иерархию, прямые выборки из дерева и т.д.

ltree - аналог?

В postgresql мне известно три способа работы с деревьями:

использование конструкции WITH RECURSIVE

Расширение ltree

Расширение tablefunc

У каждого свои плюсы и минусы. Если не найдете в документации, постараюсь разъяснить

uranic
В postgresql мне известно три способа работы с деревьями: использование конструкции WITH RECURSIVE Расширение ltree Расширение tablefunc У каждого свои плюсы и минусы. Если не найдете в документации, постараюсь разъяснить

Что-то нашел, что-то спросил.
Запросы - это одно, у них свои преимущества.
Но мне в данном случае нужна возможность хранения больших иерархий в таблице, по типу hierarhcyid в SQL Server. Ну и запросы к ним, апдейты, удаление, перенос поддеревьев.
Реально в таблице миллионы записей.

Winnipuh,
а что непонятного в доке?
По видимому, лтре вам больше подойдёт
http://www.postgresql.org/docs/9.4/static/ltree.html
И индексирование по нему супер сделано.
Ишшо премерчег
http://habrahabr.ru/post/130371/
ЗЫ
Хотя у меня и id - id_parent миллионные таблички были.

ОКТОГЕН
Winnipuh, а что непонятного в доке? По видимому, лтре вам больше подойдёт http://www.postgresql.org/docs/9.4/static/ltree.html И индексирование по нему супер сделано. Ишшо премерчег http://habrahabr.ru/post/130371/ ЗЫ Хотя у меня и id - id_parent миллионные таблички были.

вот, речь как раз о миллионных таблицах.

Как по скорости делается re-parent? т.е. перевешивание поддерева к другому паренту?

Winnipuh,

если перевешивание у вас частая операция, и длина/развесистость веток значительная -- берите стандртный рекурсивный способ и не мучайтесь. [а то много почти пустых страниц в индексе поимеете -- придется реиндексить время от времени]

ну, проиграете немного на скорости выборок ("рекурсивный" index -- seek по REFERENCE parentid(id)) -- это не суть важно. у вас есть 1000-е и более по глубине [level] ветки ?

qwwq,

да , кстати, данное листа у вас лежит в той же таблице структуры ? (в чом есть смысл для запросов -- можно составные индексы вдоль структуры и данного)
и данное это -- развесистое (много кило/мегабайтное) ?

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

Winnipuh,
Кстати, забыл про ограничения ltree:
1)Уровень вложенности не более 255(или 256)
2)метки только ASCII тоже ограниченной длинны
id - id_parent
По скорости чтобы кусок дерева перевесить на другого родича достаточно переназначить его id_parent
Очень быстрая операция. Самая быстрая, наверное в этом методе.
Медленнее - скопировать этот кусок дерева, но тоже ничего сложного особо.
первым запросом создаётся времянка - что копировать.
Вторым - расставляются новые id_parent в ней
Третьим задаётся родитель верхнего уровня.
Потом выгружается в основную таблицу и всё.
Удаление - через foreign key каскадно.
Проблем быть не должно, главное, чтобы по id - id_parent существовали индексы.
Это в самом общем случае.
Как-то так.

qwwq

Winnipuh, если перевешивание у вас частая операция, и длина/развесистость веток значительная -- берите стандртный рекурсивный способ и не мучайтесь. [а то много почти пустых страниц в индексе поимеете -- придется реиндексить время от времени] ну, проиграете немного на скорости выборок ("рекурсивный" index -- seek по REFERENCE parentid(id)) -- это не суть важно. у вас есть 1000-е и более по глубине [level] ветки ?

Операция перевешивания не частая, да и вложенности макс 128 уровней, и то это редко.