Комментарии 21
В реляционной модели не существует концепции отношения между данными. Это означает, что вы не можете определить связь между таблицами.
Думал узнал что-то новое. Но нет - сомнительный исходник и нюансы перевода.
Конечно, вы и сами можете легко нагуглить ответы на этот вопрос, однако, как я обнаружил, большинство ответов, которые вы найдете, раскрывают эту тему чересчур поверхностно.
Вот это начало оказалось вообще издевательством.
Никогда ранее не сталкивался с графовыми БД - только знал, что существуют как выделенный тип NoSQL. Признаться, надеялся найти в статье ответ на вопрос, вынесенный в заголовок статьи.
С сожалением должен констатировать - не получилось, причём от слова "совсем". Единственное следствие от прочтения и попытки осмыслить: создалось впечатление (не знаю, истинно это или нет), что всей разницы - то, что в реляционных БД делается через явные дополнительные структуры (а в случае естественных ключей к тому же вовсе даже не дополнительные), в графовых делается ссылками, а создаваемые для их поддержания структуры скрываются.. словно графовая БД - это EAV-таблица (табл.1) с сущностями, связанная на себя отношением M:N (табл.2), причём отношение является самостоятельной сущностью с атрибутом типа (табл.3).А СУБД - просто ориентирована на эффективную обработку базы именно такой структуры и оптимизирована под неё.
кто интересуется теорией, хорошо написана книга "Введения в системы баз данных", Крис Дейт, прочитал лет 40 назад, если не ошибаюсь экзамен тоже по ней сдавал, с тех пор обновлена и переиздана N+1 раз, типа рекомендую, правда новые переводы не очень, лучше читать в оригинале
см
Много воды а по сути информации нету. Графовые БД тоже как-то должны хранить объекты и отношения между ними. И деалют они это скорее всего точно также как реляционные, используют индексы с теми же принципами работы. Просто кучу джойнов обернули в синтаксический сахар.
Разрабатывал на основе реляционной бд систему отношений все со всеми. Все отношения лежали в одной таблице(в таблице грубо 4 поля: ИД_ОБЪЕКТА1,ИД_ЭКЗЕМПЛЯРА1, ИД_ОБЪЕКТА2,ИД_ЭКЗЕМПЛЯРА2 ), и выбирались одним джойном.
>И деалют они это скорее всего точно также как реляционные
Нет.
Развернутый ответ.
В любом случае хранится взаимосвязь, которая знает тип объекта 1, тип объекта2, ИД объекта1, ИД объекта2 . Иначе не найти просто связанные объекты.
Хранится это в любом случае в виде какой-то структуры(скорее всего таблицы), а для быстрого поиска индексируются. Изобретать новый велосипед? да можно но будет хуже. То что это все под капот засунули и пользователю упростили работу. ну круто.
Немного оффтопика: по запросу графовых бд сразу выходит Neo4j, у которой просто отвратительная таргетированная рекламная кампания. После этого из каждого утюга ещё долго будут абьюзить рекламой оной. Так что открывайте в инкогнито.
А вообще главное отличие реляционных и графовых бд в том, что в первой отношения задаются статически, а во второй - динамически. Все.
главное отличие реляционных и графовых бд в том, что в первой отношения задаются статически, а во второй - динамически
Эммм... не могли бы Вы быть немного подробнее, или хотя бы сопроводить сии слова ссылкой на вменяемое описание? Ибо если оперировать устоявшимися определениями этих терминов, то создаётся впечатление, что графовые БД устанавливают связи на основе не модели данных, а с привлечением некоей функции подобия (вроде similarity), и вообще чуть ли не эмпирически.
Примерно так и есть. В реляционной модели вы определяете все связи на этапе дизайна, при этом само отношение не является полноправным объектом модели. В графовых бд связи являются такими же объектами как и сущности, и ими можно манипулировать в рантайме.
Ну тогда выходит, что я прав в комментарии от 24.10.2022 в 21:26. Понятно, спасибо.
В реляционной модели вы определяете все связи на этапе дизайна
Да в принципе ничто не мешает создавать в реляционной БД динамические связи между данными и манипулировать ими в рантайме.. другое дело что механизм реализации такого связывания придётся делать и отлаживать руками, а не тупо перетаскивать мышкой одну картинку на другую, и оптимальность такого решения будет ниже, чем встроенного в СУБД.
В реляционной модели связи формулируется аналитически - с помощью формул, как в математике. По сути реляционная алгебра это такая навороченная логика, где вместо переменых со значениями true или false, используются переменные, которые представляют собой множества (отношения, таблицы). Она предлагает оперировать не отдельными фактами, а сразу целыми совокупностями.
В графовых базах связи между объектами задаются номинально - добавили связь, значит она есть, - неважно какая логика за этим стоит. Расплачиваться за гибкость приходится приличным овехедом для хранения и худшим scalability.
В реляционной модели связи формулируется аналитически - с помощью формул, как в математике.
...
В графовых базах связи между объектами задаются номинально - добавили связь, значит она есть, - неважно какая логика за этим стоит.
Ой, вот только не смешите. Добавили связь - это где-то создали запись (или что-то похожее на запись) (link_to_entity1, link_to_entity2, type). А то, что она есть, определяется чисто формулой: entity1_id = link_to_entity1 AND entity2_id = link_to_entity2, и никак иначе. Ну или не entity1_id, а pointer_to_entity1_id - то же, только вид сбоку.
И разница не в том, есть формула или нет, а в том, видима она явно или тщательно спрятана. Есть она, эта формула, есть - в любом случае.
Вот, кстати, интересный мне вопрос - есть реляционная СУБД, она хранит метаданные баз/таблиц, и на основе их клиент строит нам ER-диаграммы и наоборот, на основании изменения диаграммы корректирует метаданные. Вот эта работа с диаграммами сверху и метаданными внизу - это графовая БД?
Я долго не мог придумать название используемой мной структуры базы данных, и теперь этот пост подсказал, что такую структуру можно называть "метаграфовой". То есть это база данных действительно построенная как графовая на основе неких формализованных отношений, но одновременно такая, благодаря которой возможно выделение формализованных отношений и непосредственно контента, например, статистики вхождения той или иной позиции в ее связанности с другими позициями, определения ее подобия по старшим и по младшим связям, определения перечня абсолютно верхних и абсолютно нижних позиций иерархиии и т.п.
Мне интересно, кто-нибудь что-нибудь подобное о таком слышал, я не могу найти литературы, что кто-либо использовал подобные формы построения базы данных?
Если сам контент образует формализованные связи, то в таких отношениях неизбежны семантические циклы, про которые следует помнить при внесении информации в базу и стараться избегать. И на эту тему нельзя нигде найти ничего...
"графовые" - это те которые нам в универе называли "сетевые"?
Смешно получается, парадокс некий. RelationDB (relation - отношения) - на самом деле без отношений. Ну т.е. если запись (строку в таблице) интерпретировать как объект - то да, безусловно поля относятся к одной сущности. А вот если мыслить уже сущностями как атомарными единицами то внезапно Relation БД уже без связей между этими сущностями.
Работаю с графовыми RDF triplestore и реляционными.
Статья очень слабая:
определения из книжек, сложные в понимании начинающим
не описаны сильные и слабые стороны каждого решения (а у графов очень даже есть + и -)
не описаны области применения каждого решения
не даны примеры для лучшего закрепления материала
Странные претензии)) Автор написал то что посчитал нужным. Откуда такие требования? Вопрос о принципиальном различии (с точки зрения автора) - раскрыт (это уже с моей точки зрения). Вы почему-то ожидали каких-то там примеров, подробных сравнений для разных решений, конкретных областей применения(!), почему? Откуда такие ожидания? Кто их Вам обещал и не выполнил?
Со сложностью - может и так, но это субъективное. Кто-то начинающий, а кто-то (представьте себе) - нет.
графовыми RDF triplestore
Запятую пропустили.
По существу: чем графовая база данных отличается от реляционной?