Структура бази даних для структури даних дерев


151

Який найкращий спосіб реалізувати в базі даних настроювану (тобто структуру дерева з невідомою кількістю рівня) деревоподібну структуру даних?

Я робив це один раз, перш ніж використовувати таблицю з іноземним ключем до себе.

Які інші реалізації ви могли бачити, і чи має це реалізація сенс?



SQL Server (з 2008 року) пропонує ієрархічний тип даних
BornToCode

Відповіді:


80

Ви згадуєте про найчастіше реалізований список списку суміжності: https://blogs.msdn.microsoft.com/mvpawardprogram/2012/06/25/hierarchies-convert-adjacency-list-to-nested-sets

Є й інші моделі, включаючи матеріалізований шлях та вкладені набори: http://communities.bmc.com/communities/docs/DOC-9902

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

Крім того, Іцзік Бен-Ган має хороший огляд найпоширеніших варіантів у своїй книзі "Всередині Microsoft SQL Server 2005: T-SQL Querying".

Основні речі, які слід враховувати при виборі моделі, це:

1) Частота зміни структури - наскільки часто змінюється фактична структура дерева. Деякі моделі забезпечують кращі характеристики оновлення структури. Важливо відокремити зміни структури від інших змін даних. Наприклад, ви можете сформулювати організаційну схему компанії. Деякі люди змоделюють це як список суміжності, використовуючи ідентифікатор працівника, щоб зв’язати працівника зі своїм керівником. Зазвичай це недооптимальний підхід. Підхід, який часто працює краще, - це моделювати структуру організації окремо від самих працівників та підтримувати працівника як атрибут структури. Таким чином, коли працівник покидає компанію, сама організаційна структура не потребує змін, а лише асоціація з працівником, який пішов.

2) Чи дерево запису важке або важке для читання - деякі структури дуже добре працюють під час читання структури, але створюють додаткові накладні витрати під час запису до структури.

3) Які типи інформації вам потрібно отримати від структури - деякі структури надають перевагу в наданні певних видів інформації про структуру. Приклади включають пошук вузла та всіх його дітей, пошук вузла та всіх його батьків, пошук кількості дочірніх вузлів, що відповідають певним умовам тощо. Вам потрібно знати, яка інформація буде потрібна структурі, щоб визначити структуру, яка найкраще відповідатиме ваші потреби.


Привіт, я зіткнувся з цією самою проблемою, зазначеною у запитанні, і я хотів би поставити вам запитання щодо вищеописаних тем. Враховуючи структуру, як у темі номер один (організаційно структурована таблиця (не структурована співробітниками) з ParentId, на яку посилається в цій же таблиці), мені потрібно встановити, хто є начальником певної області. Я призначу всіх працівників цього конкретного напряму безпосередньо до нього. Куди б ви поставили начальника тієї конкретної сфери? Всередині тієї ж області чи однієї горіпи вгорі? Мій підхід полягає в тому, щоб віднести його / її до групи вище, що дає мені кращу структуру, як я думаю. Дякую.
Маркос Буарке

1
Перше посилання, здається, порушено.
Хорхе Лейтао

Відмінна відповідь. Дякую @JeremyDWill!
бобокопія

56

Погляньте на Управління ієрархічними даними в MySQL . У ньому обговорюються два підходи для зберігання та управління ієрархічними (деревоподібними) даними у реляційній базі даних.

Перший підхід - це модель списку суміжності, яку ви, по суті, описуєте: наявність зовнішнього ключа, що стосується самої таблиці. Хоча такий підхід простий, він може бути дуже неефективним для певних запитів, як-от побудова цілого дерева.

Другий підхід, обговорений у статті, - це вкладена модель набору. Цей підхід є набагато ефективнішим та гнучкішим. Детальні пояснення та приклади запитів див. У статті.


у вашому посиланні дуже цікава тема, яку обговорюють. Дякую!
Фріц

9

Якщо вам потрібно використовувати Relational DataBase для організації структури даних про дерева, то Postgresql має класний модуль ltree, який забезпечує тип даних для представлення міток даних, що зберігаються в ієрархічній структурі, подібній до дерева. Ви можете отримати ідею звідти (для отримання додаткової інформації див: http://www.postgresql.org/docs/9.0/static/ltree.html )

Зазвичай LDAP використовується для організації записів в ієрархічній структурі.


2

Мати для себе стіл із іноземним ключем має сенс для мене.

Потім ви можете використовувати загальний вираз таблиці в SQL або підключити за допомогою попереднього оператора в Oracle, щоб побудувати дерево.


У мене є таблиця журналів зі стовпцем ідентичності LogID та стовпцем ParentLogID з FK, який вказує на колонку LogID. Коли пишеться перший рядок журналу транзакції, я захоплюю SCOPE_IDENTITY (). Усі інші записи журналів записуються з цим значенням у стовпчик ParentLogID. Це дійсно корисно для групування рядків, що належать разом. Це єдиний реальний спосіб побачити, що сталося, без цього це було б величезним безладом рядків журналів від безлічі транзакцій, всі змішані разом.
КМ.

@KM - Він сказав, що "має сенс" не "не має сенсу"
Джон Раш



Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.