Способы хранения деревьев в реляционных базах данных c использованием ORM Hibernate

[furic]

Если отказаться от Lazy load (первый вариант) , все дерево подгрузится само, нет?

[Ivan_Yuriev]

Я так понимаю отказаться от Lazy имеется ввиду заменить на EAGER. Да, загрузится дерево, но для этого ORM Hibernate сгенерирует множество SQL запросов, чтоб загрузит все связанные узлы потомки, что будет неэффективно, как по количеству отправленных запросов в БД, так и затраченному на всё это времени. И к тому же, если установлен EAGER, Hibernate будет всегда загружать все связанные узлы, а это ещё и большие затраты по памяти.

[kacetal]

Для этого лучше Entity Graph использовать , а не Eager

[lwhouse]

В некоторых реляционных СУБД есть специфичные решения для работы с деревьями. В частности, я использовал ltree в PostgreSQL для Materialized Path — работает очень хорошо, GIST индекс решает проблему поиска по подстроке.

[Ivan_Yuriev]

Да, вы правы. Но к сожалению не все реляционные СУБД обладают такими решениями для работы с деревьями. В статье, я не старался привязываться к особенностям и возможностям конкретной РСУБД. К тому же для работы с ltree используются специфичные функции и запросы, которые больше напоминают регулярные выражения, а не SQL в чистом виде, который в отличии от lquery стандартизирован. Использование же не стандартизированных функций и выражений может привести к проблемам с переносимостью в будущем, если возникнет необходимость поменять РСУБД. Если же требований в обеспечении переносимости нет, то можно использовать весь имеющийся функционал предоставляемый конкретной РСУБД по максимуму. А специфичные функции и выражения РСУБД, которые могут не поддерживаться конкретным ORM фреймворком можно всегда отправлять на прямую, либо просто отключив проверку синтаксической корректности (для ORM HIBERNATE в конфигурационном файле property hibernate.query.startup_check установить в false).

[minpor]

Иван, вы меня опередили на несколько месяцев. Я точно такую же статью хотело написать, но с закосом не на hibernate. Здесь он совсем не подходит. Проще использовать JOOQ. Я же так же не парился и написал функцию в PostgreSQL. Смотрю, вы тоже использовали его. Можно чуть упростить запросы, так как местами они перегружены sql native.

[Ivan_Yuriev]

Думаю, что если у вас есть желание написать подобную статью, то не стоит себя останавливать. Я показал свои варианты реализации хранения деревьев в БД, а вы покажите свои. Соглашусь, что ORM Hibernate не идеальный фреймворк для работы с деревьями, но и реляционные БД тоже не заточены для работы с ними. Одна из причин использования нативных SQL запросов - это ограниченные и не всегда эффективные возможности самого ORM Hibernate. К примеру на данный момент Hibernate не генерирует рекурсивные запросы, а также этот запрос пока нельзя сделать с помощью JPQL. Если полагаться только на средства\возможности Hibernate, то при обходе дерева (Adjacency List) фреймворк сгенерирует множество SQL запросов, когда можно было бы решить эту задачу одним рекурсивным запросом. К тому же, я не вижу каких-либо проблем в использовании нативных SQL запросов, так как этот язык стандартизирован и если придерживаться ANSI стандарта, то не будет проблем с переносимостью в будущем, если возникнет необходимость поменять РСУБД. Полагаться же безукоризненно на ORM фреймворк и не использовать SQL - это тоже не саммый лудший подход, так как фреймворки тоже не идеальны. В статье, я приводил SQL запросы и они местами получились громоздкими, так как я старался сделать так, чтоб произвести операцию (получение потомков, получение родителей, добавления узла и т.д) над деревом минимальным числом запросов в БД и при этом подсчитывать ещё и уровень вложенности. Если громоздкие запросы разбить и обернуть в функции PostgreSQL, то естественно читабельность кода улучшиться, но я не старался привязыватся только к конкретной БД PostgreSQL, поэтому и представил всё SQL запросами. Чиатель же может взять SQL запрос и в зависимости от БД обернуть в функцию PostgreSQL или хранимую процедуру Sybase ASE или же оставить в ввиде именнованого SQL запроса, как в статье. Не отрицаю, что при детальном просмотре запросов, возможно где-то можно сделать улучшения, повысить читабельность. В целом же не вижу каких-либо препятствий или ограничений, если будет несколько статей на подобную тематику. Возможно ваши варианты реализации будут лучше. К тому же, всегда хорошо, если есть несколько вариантов решений подобных задач, будет из чего выбрать:).