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

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

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

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

Ответы

Ответ 1

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

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

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

Ответ 2

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