c # - каков наилучший постоянный подход / инструмент / библиотека для ориентированного графа

Question

Что такое лучший персистентный подход / инструмент / библиотека для направленного графа в C #. Это предполагает, что у меня есть модель класса для ориентированного графа (например, Nodes & Relationships или Vertex и Edge, если хотите), что бы вы посоветовали в отношении сохранения в базе данных SQL? (или если вы хотите, чтобы второй вопрос был, где я не указываю базу данных SQL в качестве требования)

Например, я подумал, что я бы просто пошел с таблицей отношений и таблицей узлов.

Answer 1

Я не знаком с инструментами, доступными в C #, но ваш вопрос, кажется, в основном касается хранения, а не C #.

Как вы храните DAG, без сомнения, будет зависеть от вариантов использования, которые вы имеете в виду. Вы можете представить группу обеспечения доступности баз данных в двух таблицах в реляционной базе данных, например, где одна таблица содержит информацию об узлах (A, B, C и т. Д.), А другая содержит информацию о ребрах между узлами (A -> B, A -> C и т. Д.).

Также неплохо бы использовать графическую базу данных, такую ​​как Neo4j.

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

Answer 2

Таблица Nodes и таблица отношений (связей) кажутся мне наиболее естественными, поскольку обычно (всегда?) Вы реализуете отношения «многие ко многим» в реляционной базе данных, а ориентированный граф - это, по сути, «многие ко многим». -много отображения отношений для узлов (верно?). Я полагаю, вы могли бы сохранить его в поле XML или в некотором двоичном значении, но это действительно игнорирует тот факт, что у вас есть база данных.

Если бы у вас не было базы данных, и вы писали напрямую в какой-то тип файла, я, вероятно, все равно использовал бы аналогичный механизм уникальной идентификации каждого узла с помощью ключа и отдельного определения того, как ключ значения связаны между собой.

Все это предполагает, что ваш ориентированный граф имеет множество ко многим, а не строго один ко многим. Если бы это было строго одно к многим, без циклов, я мог бы использовать XML для записи в файл (используя тот факт, что дочерние элементы в XML связаны с их родителями) или внешние ключи для записи в базу данных (что работать хорошо, даже если бы были петли).