Деревья в программировании

Наверное самый частый вид дерева в программах – справочник товаров:

Корнем тут является слово «Номенклатура», ветвями, всё более меткими: «Материалы», «Запчасти» и т.д. Сами строки – «листья» такого дерева. Уровней вложенности в таком дереве может быть сколько угодно, но обычно не очень много. Справочник товаров – номенклатуры обычно обладает максимальной вложенностью из всех имеющихся справочников.
С одной стороны такой справочник представлен в виде дерева. С другой хранится он всё равно в виде обычной таблицы, в которой кроме обычных идентификатора строки и наименования есть поле Группа, Родитель и т.д. указывающее «ветку» на которой «растёт» очередная ветка или лист.
В примере выше в справочнике есть строка «Запчасти», для которой «родителем» является ссылка на строку «Материалы» и конкретный материал «Автосигнализация», у которой «родитель» = «Запчасти».
В документы обычно вводится конкретный элемент справочника а такая структура только упорядочивает информацию при просмотре. Обычно единственная сложная выборка это выбор всех строк одной группы при просмотре всё того же справочника, когда параметром выборки является всё тот же «Родитель» задающий содержание папки, принадлежность в группе.
Древовидная структура тут присутствует только как инструмент просмотра и не создаёт каких-то дополнительных проблем.
Иногда в одну строку информации может «врастать» сразу несколько «деревьев».
Например программа для ведения сразу нескольких бухгалтерий, обменивающихся деньгами друг с другом:

Всякая бухгалтерия это проводки, у которых есть дебет, кредит, содержание проводки и сумма.
Здесь присутствуют сразу три дерева. Первое -  чисто бухгалтерское. Начинается оно не с счёта, а с типа счёта, которые видны в левом верхнем углу. Далее будут «ветви» - 1) группа счетов, 2) счёт 3) группа субсчетов, 4) субсчета.
Но бухгалтерия общая. Потому кроме бухгалтерских счетов здесь присутствует ещё и предприятия т.е откуда и куда передаются деньги даже если это внутренняя проводка внутри одной бухгалтерии. А под каждым предприятием есть ещё отделы, т.е предприятия + отделы это тоже «дерево» пусть и неглубокое.
Как это обычно и бывает, дерево тут используется для ускорения выбора:

Щёлкнув слева по группе «Темы» я справа вижу только счета из этой группы.
При выборе субсчёта появляется третье дерево. Это направления + темы (темы можно привязывать к конкретным проводкам):

Пусть меня интересует аренда по магазину. С бухгалтерской точки зрения это расход. Этот бухгалтерский взгляд позволяет увидеть, что происходило с организацией в смысле прибылей и убытков. Но у организации могут быть несколько направлений деятельности и может интересовать насколько прибыльна была одна конкретная деятельность. Привязка каждого счета ещё и к направлению (кроме бухгалтерского назначения) позволяет получить эту информацию.
К субсчёту привязан и отдел:

Это позволяло при необходимости выделить информацию не по всему направлению «Рестораны» а по конкретному ресторану.
Выбрав субсчёт можно было вводить по нему операции:

… как внутренние корреспонденции, так и перемещения в другие бухгалтерии. Всё это позволяло получить например такой отчёт:


… естественно с возможностью смотреть более детально (до субсчетов) и по конкретным отделам, предприятиям и прочему.
Т.е здесь деревья инструмент сложных выборок информации, элемент настройки системы довольно сложных отчётов.
Тут есть только одна дополнительная вещь и тоже необременительная для машины просто потому, что используется она очень редко (только в этом итоговом отчёте). В начале отчёта за январь присутствуют 80 000 потерь на конвертации. Не вдаваясь в подробности это гуляла курсовая разница, или шла конвертация в офисе по убыточному курсу. Но довольно сложный расчёт по курсовым разницам имеет смысл вести для счетов остатков, т.е для того, что тут:

… не является Приходом/расходом. Т.е обрабатывая информацию очередного субсчёта надо по веткам группа субсчетов->счёт->группа счетов добраться до этой таблицы и определить тип счета, т.е то, как с ним работать. Не так много поисков информации надо сделать, всего три. Но это нетипичная для баз данных операция. В базах данных положено выбирать что угодно одной SQL строкой а не прыгать с ветки на ветку неизвестное количество раз, запуская очередной поиск данных.
Но бывают ситуации, когда может потребоваться обработка всего, причём большого дерева. Неизвестно сколько уровней может быть в таком списке например чертежей, от сборочных до конкретных деталей:

… и если потребуется например найти сколько болтов требуется на изделие придётся каждый раз пробегать по всем веткам выбранных элементов от корня до листьев.
Никаких типовых инструментов для работы с информацией в виде таких настоящих деревьев, требующей постоянного перемещения по ветвям не существует. Потому это считается неудобной для машины работой и потенциально может быть медленной операцией. А вдруг действительно заведётся 50 уровней вложенности и для любого пустяка придётся прыгать по 50 веткам вместо выполнения одной выборки SQL запросом.
Вот, например, из упомянутой тут медицинской базы:
http://akostina76.ucoz.ru/blog/2016-11-24-3643

… поиск полного пути до найденного по подстроке названия объекта путём «прыжков» по данным до тех пор кока не будет найден корень, у которого поле Родитель он заполнено:

Так что если есть какие-то программисты – теоретики, то это поле непаханое. Объектов, которые удобно хранить в виде деревьев довольно много. Поиск по ним может требоваться, а стандартных инструментов обработки всего этого нет. А они могут быть и на уровне индексов и на уровне организации хранения данных.
p/s А может и есть механизмы, но мне они не известны.