иерархические данные в базе данных: рекурсивный запрос против таблиц закрытия против базы данных графа

Question

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

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

Мне трудно выбирать между этими вариантами.Например: учитывая, что моя СУБД допускает рекурсивные запросы, имеет ли смысл использовать таблицы замыканий и как это соотносится с решениями для графической базы данных с точки зрения удобства обслуживания и производительности?

Любые мнения / опыт будут высоко оценены!

Answer 1

Вся таблица замыканий является избыточной, если вы можете использовать рекурсивные запросы:)

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

Я провел несколько простых тестов с рекурсивными запросами в postgres.С несколькими миллионами строк в таблице запросы все еще были <10 мс для возврата всех родителей конкретного ребенка.Возвращение всех детей тоже было быстрым, в зависимости от уровня родителя.Казалось, что это больше зависит от дискового ввода-вывода, извлекающего строки, а не от скорости самого запроса.Это было сделано для одного пользователя, поэтому не уверен, как он будет работать под нагрузкой.Я подозреваю, что было бы очень быстро, если бы вы также могли держать большую часть таблицы в памяти (и правильно настроить postgres).Кластеризация таблицы по родительскому идентификатору также, похоже, помогла. </p>

Answer 2

Поле уровня («глубина») таблицы закрытия является избыточным. Для его вычисления требуется всего один рекурсивный запрос. Это примерно так.