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

Ответ 1

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

Ответ 2

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

Ответ 3

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

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

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

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

Ответ 4

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

Ответ 5

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

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

Ответ 6

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

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

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

Ответ 7

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

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

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

Ответ 8

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