Поиск отношений данных или графиков во многих таблицах SQL

Question

В моей работе есть несколько типов таблиц с множеством множеств. У меня есть приложения, которые связывают слова с другими словами (ngrams) и базами данных, которые могут связывать пользователей с другими пользователями (друзьями/последователями).

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

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

id | node1 | node2 
-------------------- 
1 | 1 | 2 
2 | 1 | 3 
3 | 1 | 4 
4 | 2 | 1 
5 | 2 | 3 
6 | 2 | 5 
7 | 3 | 1 

Например, в таблице выше, может быть очевидно, что «1» является самым популярным, так как это время связано с наиболее (на 2 & 3). Также может быть очевидно, что, возможно, «2» следует связать с «4», поскольку «2» разделяет так много отношений с «1» (и «1» связано с «4»).

Так, например, я мог бы найти:

• пути, которые соединяют узлы к другим узлам.
• полезные соединения, основанные на сходстве (рекомендации)
• группы узлов, которые разделяют родственных соединений

Другие распространенные формы отношений являются такие вещи, как user <=> friends или blog_post <=> tags.

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

Answer 1

Powergagets может создавать графики и диаграммы с использованием данных SQL.

Answer 2

Как указывает друг, ваша структура данных хороша тем, что вы пытаетесь сделать. Это вопрос о том, как вы собираетесь представлять информацию?

Что-то, что нужно изучить, это некоторые методы перемещения узлов, чтобы определить количество переходов между узлами (relavancy), количество узлов, подключенных к одному узлу (ширина), сколько хмелей может иметь значимый путь (глубина). Единственное, что я хотел бы рассмотреть, это использование, чтобы помочь определить relavancy. Это было бы более или менее счетчиком в том, сколько раз путь узла был пройден во время использования. Здесь вы можете начать назначать вес для определенного пути. Например, если путь от 1 до 5 (1 -> 2 -> 5) перемещаетс в качестве первого обхода, это может выглядеть примерно так ...

id | node1 | node2 | count 
------------------------------ 
1 | 1 | 2 | 1 
2 | 1 | 3 | 0 
3 | 1 | 4 | 0 
4 | 2 | 1 | 0 
5 | 2 | 3 | 0 
6 | 2 | 5 | 1 
7 | 3 | 1 | 0 

Этот метод может помочь определить смысл отношения между узлами, используя счетчик в качестве весового коэффициента.

Имейте в виду, что с такой структурой данных, вам нужен метод, чтобы пойти в каждом направлении (1 -> 5, и 5 -> 1)

Answer 3

Из того, что я помню о графах, Dijkstra- Алгоритмы Принна и Крускаля могут вам пригодиться. Это оба алгоритма поиска (я не могу вспомнить, являются ли они BFS или DFS ... это было некоторое время: p), которые помогут вам взять весь график и найти оптимальные пути обхода.

Они не получат вам SQL-запрос, но они предоставят математическую «плату для дайвинга», которая поможет вам получить логику для ваших SQL-запросов.

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

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

Удачи.

Answer 4

Возможно, поиск NOSQL-db будет лучшим способом решить вашу проблему. Чтобы быть более конкретным, используйте некоторый граф db, такой как neo4j, чтобы сначала представлять ваши данные sql, а не просто пересекать график, чтобы найти отношения и группы, которые вы хотите.

В вашем примере использования всегда лучше использовать график db, так как производительность в несколько раз выше, чем при использовании sql с несколькими объединениями в таблицах.