Можно ли использовать «подключить по» или «с рекурсивной» в сценарии с большими связями больших данных? - PullRequest
Новая
       47

Можно ли использовать «подключить по» или «с рекурсивной» в сценарии с большими связями больших данных?

0 голосов
/ 30 октября 2018

Представьте себе следующую ситуацию БОЛЬШИХ ДАННЫХ:

В базе данных SQL хранится 1 миллион человек. Каждый из них следует точно за 50 другими людьми.

Итак, есть такая таблица (с 50 миллионами записей): 

person1 | person2
0       |       1
0       |   2.341
0       | 212.881
..      |      ..
999.999 | 421.111
999.999 | 891.129
999.999 | 920.917

Можно ли использовать Oracle connect by или MySQL WITH RECURSIVE, чтобы выяснить, существует ли связь (возможно, через посредников) от одного человека к другому?

Будут ли эти запросы работать буквально вечно? (данные тесно связаны)

Или есть способ ограничить глубину запросов? (в данном случае: только <3 посредников) </p>

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

1 Ответ

0 голосов
/ 30 октября 2018

Возможно ли использовать Oracle connect by или MySQL WITH RECURSIVE, чтобы выяснить, есть ли соединение (возможно, более посредники) от одного человека к другому?

Да. Это цель этих функций.

Будут ли эти запросы работать буквально вечно? (данные тесно связаны)

Как и во всех запросах SQL, соответствующие индексы жизненно важны для хорошей производительности.

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

У рекурсивных общих табличных выражений (на большинстве табличных серверов, отличных от Oracle) их рекурсия может быть ограничена уровнем. Смотрите это https://dba.stackexchange.com/questions/16111/cte-running-in-infinite-loop.

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

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