Иерархические справочники с линейным временем доступа Глеб Земсков Введение
    Разработка иерархических справочников - достаточно часто встречающаяся задача в бизнес-приложениях. Существует достаточно много алгоритмов хранения дерева в реляционных СУБД. В данной статье будет рассказано об одной из таких моделей. Ее достоинства - простота реализации, быстрота выборки и добавления нового элемента, а среди недостатков можно выделить относительную сложность вставки и перемещения данных, а также конечную глубину иерархии. Но те или иные недостатки имеются в любой схеме хранения иерархических данных в РСУБД. Насколько хорош алгоритм
    Для иерархических справочников мы определим несколько наиболее часто встречающихся задач, которые затрагивают иерархию.
    получение всех потомков узла;
    получение непосредственных потомков узла;
    добавление потомка;
    удаление узла с потомками;
    перенос узла. Иерархия Дьюи (Dewey)
    Иерархический справочник может быть основан на алгоритме записи, используемом в системе десятичной классификации Дьюи (Dewey Decimal Classification). Нас в данный момент интересует не сам классификатор, а используемый в нем принцип. Попробую его описать.
    Каждый узел содержит некоторый идентификатор, уникальный среди потомков его родителя. Каждый узел содержит путь от корневого элемента к данному. Путь реализуется с помощью идентификаторов, разделенных символом точки.
    Например:
    1 Организация "Рога и копыта".
    1.1 Департамент "Рога".
    1.1.1 Отдел продажи рогов.
    1.1.2 Отдел покупки рогов.
    1.1.2.1 Группа оценки качества рогов.
    1.1.3 Отдел проката рогов.
    1.2. Департамент "Копыта"
    1.2.1 Отдел покупки копыт.
    1.2.2 Отдел продажи копыт.
    Как можно сразу заметить, при работе с подобным классификатором удобно использовать оператор LIKE. Если указывается путь, в котором начальные символы не являются маской, база данных может использовать индекс с операцией index scan с диапазонным поиском.
    Создадим тестовый пример. CREATE TABLE DEPARTMENT ( ID INT PRIMARY KEY IDENTITY(1,1), Path VARCHAR(180) UNIQUE, Position INT NOT NULL, NAME VARCHAR(128) ) GO INSERT INTO DEPARTMENT (Path, Position, NAME) VALUES ('1', 1, 'Организация "Рога и копыта"') INSERT INTO DEPARTMENT (Path, Position, NAME) VALUES ('1.1', 1, 'Департамент "Рога"') INSERT INTO DEPARTMENT (Path, Position, NAME) VALUES ('1.1.1', 1, 'Отдел продажи рогов') INSERT INTO DEPARTMENT (Path, Position, NAME) VALUES ('1.1.2', 2, 'Отдел покупки рогов') INSERT INTO DEPARTMENT (Path, Position, NAME) VALUES ('1.1.2.1', 1, 'Группа оценки качества рогов') INSERT INTO DEPARTMENT (Path, Position, NAME) VALUES ('1.1.3', 3, 'Отдел проката рогов') INSERT INTO DEPARTMENT (Path, Position, NAME) VALUES ('1.2', 2, 'Департамент "Копыта"') INSERT INTO DEPARTMENT (Path, Position, NAME) VALUES ('1.2.1', 1, 'Отдел покупки копыт') INSERT INTO DEPARTMENT (Path, Position, NAME) VALUES ('1.2.2', 2, 'Отдел продажи копыт') GO Расчет длины поля Path
    Прежде всего следует уточнить, почему поле Path имеет длину 180. Расчет прост. Количество подчиненных отделов каждого узла в справочнике вряд ли может быть больше, чем трехзначная цифра (от 0 до 999 подразделений). Такое не под силу даже таким гигантам, как Газпром. Делим количество занятых символов 4 (учитывая точку) и получаем уровень возможных вложений - 60. Цифра также запредельная. Можно подойти с другой стороны. ............