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

Question

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

@ olavk: Не похоже, что вы видели мой собственный ответ. То, как я использую, лучше, чем рекурсивные запросы:)

p.p.s. Это путь!

Answer 1

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

Answer 2

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

Answer 3

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

Answer 4

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

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

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

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

Answer 5

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

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

Answer 6

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

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

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

Answer 7

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

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

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

Answer 8

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