[Вебинар] Представление иерархических структур в реляционных БД

[@dohlik]

Доклады потом куда-нибудь выкладывать будете?

PS. У меня ссылка не работает.

[@obrovets_alexey]

ссылка ок, доскроль до «вебинары»

[@obrovets_alexey]

архив планируем там же, да

[@EvilBlueBeaver]

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

[@asm0dey]

В Java можно использовать db4objects. Оч удобно. Вероятно и другие языки имеют что-нибудь похожее…

[@Bektimirov]

Есть еще neo4j и ее порт neo4net, полностью графовая БД.

[@EvilBlueBeaver]

Ну я вот как раз под графовой neo4j и имел в виду. Все-таки лучше хранить данные более естественным образом, а не прикручивать костыли.

[@asm0dey]

А что такое графовая БД?

[@dmitriid]

Очевидно, та, для которой способ представления чего-либо в виде графов, будет нативным.

А прикрутить поверх TinkerPop'овские интерфейсы (Blueprints/Pipes/Gremlin) и вообще будет щастя.

Подробнее про грфы и графовые базы данных тута: slideshare.com/slidarko

[@EvilBlueBeaver]

Если я не ошибаюсь — это объектная СУБД. Не подскажете, как она работает в сравнении со связкой РСУБД + hibernate в плане удобства, скорости и так далее? Все таки hibernate это по сути костыль.

[@asm0dey]

Ну, по очевидным причинам для работы с полностью объектной БД никакой хибер не нужен.
Ведь по сути хибернейт это способ представить РСУБД в объектном виде, что удобно, но не натвино.
Объектная БД позволяет работать с чистыми джавовскими объектами.

[@EvilBlueBeaver]

Я об этом догадывался ;) я имею в виду есть ли удобные механизмы выборки объектов, подходящих под определенное условие (естественно с использованием индексов), какова относительная скорость работы, если допустим похожую структуру реализовать в связке hibernate + РСУБД на типовых выборках?

[@asm0dey]

Насчет выборки — ИМХО механизмы мегаудобные.
Предлагаю почитать более чем понятную доку

В той же доке хорошо описано как работать с индексами. ИМХО весьма прозрачно.

Для выборок db4o поддерживает ажно три разных языка, что тоже удобно.

[@asm0dey]

Прошу прощения, неправильно понял ваш вопрос.
Честно говоря, производительность не сравнивал (да и какой смысл — задачи-то разные...)
Нет необходимости нормализации, нет костылей, с ней связанных. Нужно хранить мэпы — храните мэпы, в РСУБД это решается не нативным образом. Нужно хранить документы в документах? Не проблема. А в РСУБД решается созданием дополнительных таблиц и составлением хитрых джойн-запросов…

[@EvilBlueBeaver]

См. выше вопрос по поводу индексов в частности.

[@bit]

По-моему ADABAS на IBM-360 была иерархическая. Интересно, сейчас есть что-то подобное?
Есть еще сетевая модель БД. Комерческая реализация была сделана Raima corp. (если правильно написал) — dbVista звали ту БД. Вроде она и сейчас живет. У меня где-то лежат сырцы ее опенсорсного варианта — db-Star (db-linux). Одно время они были в инете, но сейчас вычистили.

[@AlexanderYastrebov]

По теме, может кому пригодится
www.slideshare.net/quipo/trees-in-the-database-advanced-data-structures
dev.mysql.com/tech-resources/articles/hierarchical-data.html

[@dmitriid]

Про графы и графовые БД: www.slideshare.net/slidarko

[@Bektimirov]

На Хабре была статья про иерархические запросы, там тоже рассматривалась структура Adjacency List.

[@si14]

Во всех ведуших СУБД есть поддержка рекурсивных CTE (постгрес, оракля, мс), полностью решающие проблему иерархических данных в таблицах — работают очень быстро, записываются удобно и логично. Нету её только в мускуле. На этом фоне достаточно странно выглядит новость о «цикле вебинаров о хранении иерархических данных» — примерно как «цикл вебинаров о велосипедостроении». Я не понимаю, в чём причина такого игнорирования крайне важной фичи SQL (они даже в стандарте есть, не помню только, 92 или позже) — на моём опыте относительное количество знающих о СТЕ достаточно мало. Мускуль виноват, что ли?

[@EvilBlueBeaver]

То, что вы описали, это есть лишь один из вариантов хранения (с parent_id) и СУБД просто предоставляют удобный способ этим пользоваться, однако существуют и другие способы хранения, оптимизированные для других операций.
Для некоторых задач не нужно ничего сложнее adjacency list (для которого как раз синтаксический сахар и предназначен), а некоторые придется описывать с помощью nested sets например.

В общем это я к чему. К тому, что как хранить иерархические данные в РСУБД зависит от типа решаемых задач.

P.S. Случаем никто не замерял скорость работы данных рекурсивных CTE, если надо выбрать все поддерево (например посчитать сумму опреленного поля у узла и всех его подузлов в полную глубину) на больших таблицах?

[@dmitriid]

Помимо иерархических есть и не иерархические. И по ним еще иногда хочется делать произвольные выборки.

[@ivaer]

не пойму, что тут можно новое рассказать про Adjacency List, вроде итак всё уже по несколько раз пересказано. Другое дело что то новое изобрели…

[@Shopin]

Скажите, пожалуйста, как у вас проводятся вебинары.
На клиенте должен стоять Live Meeting и для зарегистрившихся будет опубликована ссылка?