по сути является набором графов. Для упрощение запросов на чтение в таблице на каждый граф одна строчка и поле array с набором вершин. Все работает, но добавлять данные в такую структуру очень медленно. При каждом обновлении вершин нужно смотреть, что новая связь не образовала связей между существующими графами — тогда их нужно объединить в один, а старые удалить. При объединение нужно удалять повторы вершин еще )
Пока из вариантов вижу делать отдельно нормализованное представление данных в виде m2m, грузить туда, а после загрузки данных запускать синхронизацию и перегонять это в денормализованный вид с полем array.
Может еще варианты какие-то есть?) Может postgres вообще лучше тут не использовать? :D
если очень надо сделайте 2 уровня: уровень хранения (куда выбдете сохранять и где информация будет храниться) и уровень представления (тот слой с которым вы будете работать, так как вам удобно)...
графы обычно хранят в виде adjacency list. я бы предложил две таблицы. первая — с данными: graph ::: gra_id, <ANY DATA> вторая — со связями: graph_links ::: gra_id, gra_link если б было дерево (частный случай графа, у каждой вершины — только один родитель), можно бы было ограничиться одной таблицей. потребуется некоторая "обвязка" (рекурсивными) функциями, чтобы выборки делались в виде: SELECT * FROM graph_children_of(5) INNER JOIN graph USING(gra_id) SELECT * FROM graph_path_of(5) INNER JOIN graph USING(gra_id) все запросы будут проходить только по PK, т.е. всё будет очень быстро работать.
Разве в таком случае не будет довольно медленное чтение? У нас линков будут десятки/сотни миллионов. Чтобы раскрутить все транзитивно связанные узлы понадобится много рекурсивных запросов по такой схеме.
Или я не так понял идею?
хм, да, за циклами в связях надо будет следить. я привык только с деревьями, упустил этот момент =)
Обсуждают сегодня