Комментарии 24
Доклады потом куда-нибудь выкладывать будете?
PS. У меня ссылка не работает.
PS. У меня ссылка не работает.
А я вот все больше убеждаюсь, что не предназначены реляционные СУБД для хранения иерархических данных. Любой из способов хранения содержит те или иные недостатки. Наверняка существуют какие-то специализированные СУБД, например те же графовые.
В Java можно использовать db4objects. Оч удобно. Вероятно и другие языки имеют что-нибудь похожее…
Ну я вот как раз под графовой neo4j и имел в виду. Все-таки лучше хранить данные более естественным образом, а не прикручивать костыли.
А что такое графовая БД?
Очевидно, та, для которой способ представления чего-либо в виде графов, будет нативным.
А прикрутить поверх TinkerPop'овские интерфейсы (Blueprints/Pipes/Gremlin) и вообще будет щастя.
Подробнее про грфы и графовые базы данных тута: slideshare.com/slidarko
А прикрутить поверх TinkerPop'овские интерфейсы (Blueprints/Pipes/Gremlin) и вообще будет щастя.
Подробнее про грфы и графовые базы данных тута: slideshare.com/slidarko
Если я не ошибаюсь — это объектная СУБД. Не подскажете, как она работает в сравнении со связкой РСУБД + hibernate в плане удобства, скорости и так далее? Все таки hibernate это по сути костыль.
Ну, по очевидным причинам для работы с полностью объектной БД никакой хибер не нужен.
Ведь по сути хибернейт это способ представить РСУБД в объектном виде, что удобно, но не натвино.
Объектная БД позволяет работать с чистыми джавовскими объектами.
Ведь по сути хибернейт это способ представить РСУБД в объектном виде, что удобно, но не натвино.
Объектная БД позволяет работать с чистыми джавовскими объектами.
Я об этом догадывался ;) я имею в виду есть ли удобные механизмы выборки объектов, подходящих под определенное условие (естественно с использованием индексов), какова относительная скорость работы, если допустим похожую структуру реализовать в связке hibernate + РСУБД на типовых выборках?
Насчет выборки — ИМХО механизмы мегаудобные.
Предлагаю почитать более чем понятную доку
В той же доке хорошо описано как работать с индексами. ИМХО весьма прозрачно.
Для выборок db4o поддерживает ажно три разных языка, что тоже удобно.
Предлагаю почитать более чем понятную доку
В той же доке хорошо описано как работать с индексами. ИМХО весьма прозрачно.
Для выборок db4o поддерживает ажно три разных языка, что тоже удобно.
Прошу прощения, неправильно понял ваш вопрос.
Честно говоря, производительность не сравнивал (да и какой смысл — задачи-то разные...)
Нет необходимости нормализации, нет костылей, с ней связанных. Нужно хранить мэпы — храните мэпы, в РСУБД это решается не нативным образом. Нужно хранить документы в документах? Не проблема. А в РСУБД решается созданием дополнительных таблиц и составлением хитрых джойн-запросов…
Честно говоря, производительность не сравнивал (да и какой смысл — задачи-то разные...)
Нет необходимости нормализации, нет костылей, с ней связанных. Нужно хранить мэпы — храните мэпы, в РСУБД это решается не нативным образом. Нужно хранить документы в документах? Не проблема. А в РСУБД решается созданием дополнительных таблиц и составлением хитрых джойн-запросов…
По-моему ADABAS на IBM-360 была иерархическая. Интересно, сейчас есть что-то подобное?
Есть еще сетевая модель БД. Комерческая реализация была сделана Raima corp. (если правильно написал) — dbVista звали ту БД. Вроде она и сейчас живет. У меня где-то лежат сырцы ее опенсорсного варианта — db-Star (db-linux). Одно время они были в инете, но сейчас вычистили.
Есть еще сетевая модель БД. Комерческая реализация была сделана Raima corp. (если правильно написал) — dbVista звали ту БД. Вроде она и сейчас живет. У меня где-то лежат сырцы ее опенсорсного варианта — db-Star (db-linux). Одно время они были в инете, но сейчас вычистили.
Про графы и графовые БД: www.slideshare.net/slidarko
На Хабре была статья про иерархические запросы, там тоже рассматривалась структура Adjacency List.
Во всех ведуших СУБД есть поддержка рекурсивных CTE (постгрес, оракля, мс), полностью решающие проблему иерархических данных в таблицах — работают очень быстро, записываются удобно и логично. Нету её только в мускуле. На этом фоне достаточно странно выглядит новость о «цикле вебинаров о хранении иерархических данных» — примерно как «цикл вебинаров о велосипедостроении». Я не понимаю, в чём причина такого игнорирования крайне важной фичи SQL (они даже в стандарте есть, не помню только, 92 или позже) — на моём опыте относительное количество знающих о СТЕ достаточно мало. Мускуль виноват, что ли?
То, что вы описали, это есть лишь один из вариантов хранения (с parent_id) и СУБД просто предоставляют удобный способ этим пользоваться, однако существуют и другие способы хранения, оптимизированные для других операций.
Для некоторых задач не нужно ничего сложнее adjacency list (для которого как раз синтаксический сахар и предназначен), а некоторые придется описывать с помощью nested sets например.
В общем это я к чему. К тому, что как хранить иерархические данные в РСУБД зависит от типа решаемых задач.
P.S. Случаем никто не замерял скорость работы данных рекурсивных CTE, если надо выбрать все поддерево (например посчитать сумму опреленного поля у узла и всех его подузлов в полную глубину) на больших таблицах?
Для некоторых задач не нужно ничего сложнее adjacency list (для которого как раз синтаксический сахар и предназначен), а некоторые придется описывать с помощью nested sets например.
В общем это я к чему. К тому, что как хранить иерархические данные в РСУБД зависит от типа решаемых задач.
P.S. Случаем никто не замерял скорость работы данных рекурсивных CTE, если надо выбрать все поддерево (например посчитать сумму опреленного поля у узла и всех его подузлов в полную глубину) на больших таблицах?
Помимо иерархических есть и не иерархические. И по ним еще иногда хочется делать произвольные выборки.
не пойму, что тут можно новое рассказать про Adjacency List, вроде итак всё уже по несколько раз пересказано. Другое дело что то новое изобрели…
Скажите, пожалуйста, как у вас проводятся вебинары.
На клиенте должен стоять Live Meeting и для зарегистрившихся будет опубликована ссылка?
На клиенте должен стоять Live Meeting и для зарегистрившихся будет опубликована ссылка?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
[Вебинар] Представление иерархических структур в реляционных БД