Каким будет наилучший способ реализации дерева данных с настраиваемой структурой (значение, древовидная структура с неизвестным числом уровней) в базе данных?
Я сделал это один раз, прежде чем использовать таблицу с внешним ключом.
Какие другие реализации вы могли бы увидеть, и имеет ли смысл эта реализация?
Вы упомянули наиболее часто реализуемый, который является списком Adjacency: https://blogs.msdn.microsoft.com/mvpawardprogram/2012/06/25/hierarchies-convert-adjacency-list-to-nested-sets
Существуют и другие модели, включая материализованный путь и вложенные наборы: http://communities.bmc.com/communities/docs/DOC-9902
Joe Celko написал книгу на эту тему, которая является хорошей ссылкой на общую перспективу SQL (она упоминается в ссылке вложенного набора статей выше).
Кроме того, Ицик Бен-Ганн имеет хороший обзор наиболее распространенных вариантов в своей книге "Внутри Microsoft SQL Server 2005: запрос T-SQL".
Основные моменты, которые следует учитывать при выборе модели:
1) Частота изменения структуры - как часто меняется фактическая структура дерева. Некоторые модели обеспечивают лучшие характеристики обновления структуры. Однако важно отделить изменения структуры от других изменений данных. Например, вы можете выбрать модель организационной структуры компании. Некоторые люди будут моделировать это как список смежности, используя идентификатор сотрудника, чтобы связать сотрудника с его руководителем. Это, как правило, субоптимальный подход. Подход, который часто работает лучше, состоит в том, чтобы моделировать структуру организации отдельно от самих сотрудников и поддерживать сотрудника как атрибут структуры. Таким образом, когда сотрудник покидает компанию, сама организационная структура не нуждается в изменениях, а только связь с оставшимся сотрудником.
2) Является ли дерево тяжелым или тяжелым для чтения - некоторые структуры работают очень хорошо при чтении структуры, но при записи в структуру возникают дополнительные накладные расходы.
3) Какие типы информации вам нужны для получения из структуры - некоторые структуры превосходят при предоставлении определенных видов информации о структуре. Примеры включают поиск node и всех его дочерних элементов, поиск node и всех его родителей, поиск количества дочерних узлов, удовлетворяющих определенным условиям, и т.д. Вам нужно знать, какая информация потребуется от структуры для определения структуры что наилучшим образом соответствует вашим потребностям.
Посмотрите Управление иерархическими данными в MySQL. В нем обсуждается два подхода к хранению и управлению иерархическими (древовидными) данными в реляционной базе данных.
Первый подход - это модель списка смежности, что вы, по сути, описываете: наличие внешнего ключа, который относится к самой таблице. Хотя этот подход прост, он может быть очень неэффективным для некоторых запросов, например, для построения всего дерева.
Второй подход, обсуждаемый в статье, - это вложенная модель набора. Этот подход намного эффективнее и гибко. Обратитесь к статье за подробными пояснениями и примерными запросами.
Если вам необходимо использовать Relational DataBase для организации структуры древовидных данных, Postgresql имеет классный модуль ltree, который предоставляет тип данных для представления меток данных, хранящихся в иерархической древовидной структуре. Вы можете получить эту идею оттуда. (Для получения дополнительной информации см.: http://www.postgresql.org/docs/9.0/static/ltree.html)
В общем LDAP используется для организации записей в иерархической структуре.
Наличие таблицы с внешним ключом для меня имеет смысл для меня.
Затем вы можете использовать общее табличное выражение в SQL или подключить предыдущий оператор в Oracle для создания своего дерева.
Фантастический набор готовых к использованию функций, которые можно использовать с моделью списка смежности, чтобы сделать жизнь проще.
http://www.artfulsoftware.com/mysqlbook/sampler/mysqled1ch20.html
Я использовал следующую реализацию SQL SERVER 2005. Проверьте здесь
Если кто-либо, использующий MS SQL Server 2008 и более поздних версий, задается этим вопросом: в SQL Server 2008 и более поздних версиях появилась новая функция "ierarchyId ", разработанная специально для этой задачи.
Больше информации на https://docs.microsoft.com/en-us/sql/relational-databases/hierarchical-data-sql-server