Как и все говорили, этот ответ полностью зависит от того, что вы делаете и почему вы это делаете.
Базы данных отлично подходят для извлечения наборов данных, а также для категоризации и обобщения этих данных. Вот для чего они предназначены (среди многих других вещей).
Они не очень хорошо описывают сложные отношения между отдельными ценностями (x глубокие отношения n: m). Структуры произвольного доступа из движения NoSQL лучше в этом.
Если вы действительно хотите использовать классическую СУБД, вы можете смоделировать проблему в виде графа в БД, используя концепцию ребер и узлов. Узлы имеют 0: N ребер и 0: N атрибутов / значений (EAV, как предложено выше). Края имеют 2 узла и, возможно, вес.
Вы можете смоделировать это с:
NODE ([node_id, entity, attribute], value)
EDGE ([src_node_id, dest_node_id], weight)
Создание отношения между узлами (ребро) требует простого добавления значения в таблицу EDGE.
Обход структуры требует рекурсивного набора запросов, которые находят все возможные шаги текущего узла и затем выбирают один, чтобы перейти к следующему узлу. Это может быть интенсивно для СУБД.
EG //
SELECT dest_node_id
FROM EDGE
WHERE src_node_id = <<This Node ID>>
ORDER BY weight ASC
LIMIT 1
Вспенить, промыть и повторить для того, насколько далеко вы хотите идти (это предполагает, что вес - это стоимость, а не показатель выгоды, и что график является ориентированным графом).