Меня очень заинтересовала Ваша статья про иерархические структуры в реляционных базах данных. Я занимаюсь разработкой системы, одной из частей которой является электронный вариант каталога деталей и узлов. Иерархическа структура для такого каталога является единственно возможной:
изделие состоит из подсистем, подсистема - из агрегатов, агрегат - из узлов, узел - из деталей, деталь может включать в себя более мелкие детали
(винты, гайки и т.п.). Я перебрал много вариантов организации такой иерархической структуры в виде реляционной базы данных; был у меня и тот, что рассмотрен в Вашей статье.
Но в моем случае есть некоторые особенности, не позволяющие воспользоватьс приведенной схемой без изменений:
1) Каждая деталь имеет ряд атрибутов, важнейшими из которых являютс наименование и обозначение (чертежный номер). Напр.:
Соединение поворотное 3.56.1205.1045.00
Кольцо 5127А-153
Выбрать для отображения в TTreeView один из этих атрибутов нельзя: ни наименование без обозначения, ни обозначение без наименования не дают достаточной информации человеку, работающему с такой системой. Можно было бы объединить наименование и обозначение в одну строку, но при этом, из-за значительного разброса в длине строк, теряется наглядность.
2) Если деталь включает в себя крепеж, складывается ситуация, когда родитель не является суммой своих детей. Поэтому было бы неправильно
отображать список детей, как содержимое родителя.

В связи с этими особенностями более предпочтительной мне показалась следующая схема:
Детали одного уровня отображаются вместе со своими атрибутами в компоненте TDBGrid. Такое представление аналогично Explorer Windows 95, работающему в режиме Таблица.
При активизации одного из элементов происходит:
- "проваливание" на более глубокий уровень, если активизируется узел, содержащая много деталей;
- "распахивание" элемента , если активизируется деталь, содержаща крепеж.
Под распахиванием я подразумеваю отображение детей в списке после родител с некоторым отступом. Напр.:

Кронштейн
Шарнир
Угольник

Кронштейн
Шарнир
Винт
Гайка
Угольник

При повторной активизации "распахнутого" элемента он "запахивается" :-).
Кстати, этот же принцип представления информации используется в бумажном оригинале каталога.

Подходящей структурой базы данных будет следующая:

ID OWNER PARENT NAME
1 0 0 Соединение поворотное
2 1 1 Кронштейн
3 1 1 Шарнир
4 1 3 Винт
5 1 3 Гайка
6 1 1 Угольник

Поле OWNER дает нам информацию для отображения деталей одного уровня, а PARENT содержит информацию о отношениях родитель-потомок.
Ситуация похожа на организацию пользовательского интерфейса в Delphi. Для реализации "распахивающихся" элементов можно применить фильтрацию записей на клиентской машине в сочетании с ведением списка распахнутых элементов данного уровня.

С уважением,
Мухачев Евгений.