Как сохранить каталог / иерархию / древовидную структуру в базе данных?

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

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

Надеюсь это поможет.

Я никоим образом не связан с этим сайтом

Вы используете SQL Server 2005? Рекурсивные запросы делает запросы к иерархическим данным более элегантными.

Обновлено: я действительно думаю, что материализованные пути - это что-то вроде взлома. Путь содержит ненормализованные избыточные данные, и вам нужно использовать триггеры или что-то еще, чтобы их обновлять. Например. если узел меняет родителя, необходимо обновить пути всего поддерева. И запросы поддерева должны использовать некрасивое сопоставление подстрок, а не элегантное и быстрое соединение.

Типичный способ - это таблица с внешним ключом (например, «ParentId») на себя.

Также существует модель деревьев с вложенными наборами, которая имеет некоторые преимущества по сравнению с моделью ParentID. См. http://www.evanpetersen.com/item/nested-sets.html и http://falsinsoft.blogspot.nl/2013/01/tree-in-sql-database-nested-set-model.html.

Есть много способов для хранения иерархий в базах данных SQL. Какой из них выбрать, зависит от того, какой продукт СУБД вы используете и как будут использоваться данные. Поскольку вы использовали тег MSSQL2005, я думаю, вам следует начать рассматривать модель «Список смежности»; если вы обнаружите, что он плохо работает для вашего приложения, взгляните на Сравнение Вадима Тропашко, в котором подчеркиваются различия между моделями с акцентом на нескольких характеристиках производительности.

Если вы используете Sql Server 2008, возможно, вам стоит проверить новый тип данных иерархия.

Я столкнулся с подобной проблемой в одном из моих проектов. У нас была огромная иерархия, которая будет расти вечно. Мне нужно было быстро пройти его, а затем найти нужную группу после некоторых сложных проверок. Вместо того, чтобы идти к SQL Server и ломать голову, как я могу сделать это эффективно там, когда я знал, что рекурсивные запросы - единственное жизнеспособное решение. Но знаете ли вы, что в рекурсивных запросах вообще возможна оптимизация? Есть ли гарантия, что ваша иерархия не будет увеличиваться в будущем и в один прекрасный день вы обнаружите, что ваши рекурсивные запросы слишком медленны для использования в производстве?

Итак, я решил попробовать Neo4J. Это база данных графов со множеством встроенных полезных алгоритмов, удивительно быстрым обходом с хорошей документацией и примерами. Сохраните иерархию в Neo4J и получите доступ к иерархии с помощью Thrift Service (или чего-то еще). Да, вам нужно будет написать код, который будет интегрировать ваши SQL-запросы с Neo4J, но у вас будет масштабируемое и более перспективное решение.

Надеюсь, вы найдете это полезным.

Вопрос аналогичен закрытому этот вопрос. Я нашел ответы на оба вопроса очень полезными в моих поисках, и в конечном итоге они привели меня к руководству MongoDB, в котором представлены 5 различных способов моделирования древовидных структур: https://docs.mongodb.com/manual/applications/data-models-tree-structures/

Хотя MongoDB не является реляционной базой данных, представленные модели применимы к реляционным базам данных, а также к другим форматам, таким как JSON. Вам явно необходимо выяснить, какая модель подходит, исходя из представленных плюсов и минусов.

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