Как хранить граф в реляционной БД?
Т.е. указываем одни рёбра. Кажется, это не очень быстро. Посоветуйте, пожалуйста, чтива.
P.S. Основная база — PostgreSQL. Хотелось бы оставить все данные в ней.
wyldrodney ☆
07.12.13 14:00:12 MSK
В одной таблице хранить узлы, а в другой — связи между узлами?
POLTER ★★
( 07.12.13 14:02:39 MSK )
Смотря какие операции нужны. Хранить можно много как, хоть в JSON засунуть и заgzipовать в BLOB-поле.
Legioner ★★★★★
( 07.12.13 14:04:33 MSK )
Ответ на: комментарий от POLTER 07.12.13 14:02:39 MSK
А как обходить граф? Имеет ли смысл хранить во второй таблице смежные вершины? Если понадобится писать свойства рёбер?
wyldrodney ☆
( 07.12.13 14:13:06 MSK ) автор топика
Ответ на: комментарий от wyldrodney 07.12.13 14:13:06 MSK
обходить просто — берем верхнюю вершину, достаем связи для нее из таблицы связей, переходим по ним и так далее. В принципе, можно хранить там и свойства ребер, ведь это и есть ребра по сути) Только во второй таблице нужно хранить в том порядке, чтоб обходить.
POLTER ★★
( 07.12.13 20:24:03 MSK )
У этого модуля есть ограничение на 65 килобайт на поле. Стало интересно: сколько пользователей «влезет».
У меня соц. сеть с реферальной регистрацией. Пусть, каждый пользователь приводит в среднем 1.001 пользователя (реферала).
Так, если корневой пользователь наберёт 50 000 потомков, а это 9 999 552 пользователей, запись пути от корневого родителя до любого предка будет не более 58 995 симолов. Масштаб! 🙂
P.S. В документации говорится о 65Kb. Хочется верить, что это байты, но никак не биты: привык что байты обозначаются большой «B».
wyldrodney ☆
( 08.12.13 07:36:43 MSK ) автор топика
Охренеть, Вылдротень вернулсо!
Как твоя игра поживает? Как секс-зависимость? Велком бек он боард 🙂
anonymous
( 08.12.13 07:40:28 MSK )
Ответ на: комментарий от anonymous 08.12.13 07:40:28 MSK
Жена вчера пообещала уйти. Хе-хе, куда она с Бали денется?
wyldrodney ☆
( 08.12.13 07:43:29 MSK ) автор топика
Ответ на: комментарий от wyldrodney 08.12.13 07:43:29 MSK
Ты её заэтосамое штоле? 🙂 А чё на Бали, отдыхаешь аль дауншифтишь?
anonymous
( 08.12.13 07:49:42 MSK )
Ответ на: комментарий от anonymous 08.12.13 07:49:42 MSK
Если откровенно, она недолюбливает ЛОР, и в этом корень разногласий.
Отдыха тут нет: пива нет, водки нет, мяса нет, бляди страшные, местные — быдло, ни одного театра. Тут — фрилансю 🙂
wyldrodney ☆
( 08.12.13 07:55:50 MSK ) автор топика
Ответ на: комментарий от wyldrodney 08.12.13 07:55:50 MSK
Если откровенно, она недолюбливает ЛОР, и в этом корень разногласий.
Охренеть! =-O Ты же в последнее время почти не заходишь. Да и мало ли ты где сидишь. Похоже просто на попытку дое*ться на пустом месте, сорри 🙁
Отдыха тут нет: пива нет, водки нет, мяса нет, бляди страшные, местные — быдло, ни одного театра. Тут — фрилансю 🙂
Вали оттуда поскорее, у этой страны нет будущего, гореть ей в клоаке огненной! Чо, неужели нет стран с похожим климатом, но без вышеописанных critical bug’ов?
anonymous
( 08.12.13 07:59:43 MSK )
Ответ на: комментарий от anonymous 08.12.13 07:59:43 MSK
На Тенерифе мне понравилось, +23..+25 круглый год, правда, дожди всего пять дней в году. Пива хоть залейся. Девки отличные. Жрачка вкусная. Народ цивильный, университет даже есть, джазовые фестивали проводятся.
Но — надо знать испанский, иначе не выкрутишься. И иммиграционные правила жёсткие шо пездец, а сколько там можно по туристической визе тусить — не помню.
Обработка графов в SQL Server и Базы данных SQL Azure
SQL Server предлагает возможности базы данных графа для моделирования связей «многие ко многим». Связи графов интегрируются в Transact-SQL и получают преимущества использования SQL Server в качестве базовой системы управления базами данных.
Что такое графовая база данных?
База данных графа представляет собой коллекцию узлов (или вершин) и ребер (или связей). Узел представляет сущность (например, пользователя или организацию), а ребро — связь между двумя узлами, которые оно соединяет (например, отметки «Нравится» или друзья). Оба узла и ребра могут иметь свойства, связанные с ними. Ниже приведены некоторые функции, благодаря которым графовая база данных является уникальной.
- Ребра или связи в графовой базе данных являются сущностями первого класса, с которым могут быть связаны атрибуты или свойства.
- Одно ребро может гибко соединить несколько узлов в графовой базе данных.
- Вы можете легко выразить запросы на сопоставление шаблонов и навигацию со множеством переходов.
- Вы можно легко выразить транзитивное замыкание и полиморфные запросы.
Когда следует использовать базу данных графа
Реляционная база данных может достичь всего, что может сделать графовая база данных. Однако база данных графа упрощает выражение определенных типов запросов. Кроме того, при определенных оптимизациях некоторые запросы могут выполняться лучше. Ваше решение выбрать реляционную или графовую базу данных основано на следующих факторах:
- Приложение имеет иерархические данные. Тип данных HierarchyID можно использовать для реализации иерархий, но имеет некоторые ограничения. Например, он не позволяет хранить несколько родителей для узла.
- Приложение имеет сложные связи «многие ко многим»; По мере развития приложения добавляются новые связи.
- Вам необходимо анализировать взаимосвязанные данные и связи.
Функции Graph, представленные в SQL Server 2017 (14.x)
В SQL Server 2017 появились следующие функции.
Создание объектов графа
Расширения Transact-SQL позволяют пользователям создавать узлы или пограничные таблицы. Оба узла и ребра могут иметь свойства, связанные с ними. Так как узлы и ребер хранятся в виде таблиц, все операции, поддерживаемые реляционными таблицами, поддерживаются на узле или пограничной таблице. Ниже приведен пример:
CREATE TABLE Person (ID INTEGER PRIMARY KEY, Name VARCHAR(100), Age INT) AS NODE; CREATE TABLE friends (StartDate date) AS EDGE; На следующей схеме показано, как узлы и ребра хранятся в виде таблиц.
Расширения языка запросов
Новое MATCH предложение представлено для поддержки сопоставления шаблонов и много прыжков навигации по графу. Функция MATCH использует синтаксис стиля ASCII для сопоставления шаблонов. Например, чтобы найти друзей «Джон»:
-- Find friends of John SELECT Person2.Name FROM Person Person1, Friends, Person Person2 WHERE MATCH(Person1-(Friends)->Person2) AND Person1.Name = 'John'; Полностью интегрирована в ядро СУБД SQL Server
Расширения Graph полностью интегрированы в подсистему SQL Server. Используйте тот же механизм хранения, метаданные, обработчик запросов и т. д. для хранения и запроса данных графа. Запрос между графами и реляционными данными в одном запросе. Объединение возможностей графа с другими технологиями SQL Server, такими как индексы columnstore, службы ВЫСОКОЙ доступности, службы R и т. д. Граф SQL также поддерживает все функции безопасности и соответствия требованиям, доступные в SQL Server.
Инструментирование и экосистема
Преимущества существующих средств и экосистемы, которые предлагает SQL Server. Такие инструменты, как резервное копирование и восстановление, импорт и экспорт, BCP просто работают над полем. Другие средства или службы, такие как SSIS, SSRS или Power BI, работают с таблицами графов, так же, как они работают с реляционными таблицами.
Ограничения границ
Ограничение границ определяется в таблице пограничных вычислений графа и представляет собой пару таблиц узлов, которые могут подключаться к заданному типу ребра. Ограничения пограничных вычислений помогают разработчикам ограничить тип узлов, которые может подключить данный край.
Дополнительные сведения о создании и использовании пограничных ограничений см. в разделе «Ограничения пограничных вычислений».
Слияние DML
Инструкция MERGE выполняет операции вставки, обновления или удаления целевой таблицы на основе результатов соединения с исходной таблицей. Например, можно синхронизировать две таблицы, вставляя, обновляя или удаляя строки в целевую таблицу на основе различий между целевой таблицей и исходной таблицей. Использование предикатов MATCH в инструкции MERGE теперь поддерживается в Базе данных SQL Azure и vNext SQL Server. То есть теперь можно объединить текущие данные графа (узлы или пограничные таблицы) с новыми данными с помощью предикатов MATCH, чтобы указать связи графов в одной инструкции вместо отдельных инструкций INSERT/UPDATE/DELETE.
Дополнительные сведения о том, как совпадение можно использовать в слиянии DML, см. в инструкции MERGE.
Кратчайший путь
Функция SHORTEST_PATH находит кратчайший путь между двумя узлами в графе или начиная с заданного узла ко всем остальным узлам в графе. SHORTEST PATH также можно использовать для поиска транзитивного закрытия или для произвольных обходов длины в графе.
Далее
- Чтение базы данных SQL Graph — архитектура
- Сведения о начале работы с SQL Graph см. в примере базы данных SQL Graph
как хранить в БД граф value object
Как видно из названия классов — объекты типа EntityA являются сущностями(в терминах DDD), а объекты типов ValueObjectA и ValueObjectB — объектами значениями. Нужно определить каким образом хранить в БД данный граф объектов. Что вызвало у меня трудности: связь между EntityA и ValueObjectA — один-ко-многим, между ValueObjectA и ValueObjectB тоже один-ко-многим. В этом случае логично для каждого класса создать отдельную таблицу в БД и связать эти таблицы между собой. Проблема возникает в связывании этих таблиц. Я не хочу добавлять в классы ValueObjectA и ValueObjectB идентификаторы, хочу чтобы они остались полноценными value object. В этом случае связать таблицы EntityA и ValueObjectA очень просто, а вот как связать таблицы ValueObjectA и ValueObjectB — я ума не приложу.
Yii Framework
Узел 7 ссылается на узел 1.
Насколько я понимаю это граф. У меня возникла проблема как его лутше сохранять в БД ? И потом обходить его.
Все что нашел ето для каждого узла отдельно хранить в список всех соседних узлов к примеру в json. Или вде таблици в первшой все узлы во второй все переходы.
Есть ли какие то готовые поведения для этого? Все что нарыл это nested set но он не подходит так как листя у меня могут ссылатся на верхнее уровни. вплоть до корня.
Есть какие то идеи по етому поводу?