Задача в следующем...

Есть персонал, для которого нужно организовать авторизацию на веб странице(это еще не проблема).
При этом персоны из этого персонала относятся к друг другу как 
начальник_уровень0(Персона1, Персона2)   //Персона1 есть начальник персоны2;
начальник_уровень1(Персона1, Персона2) 
начальник_уровень2(Персона1, Персона2) 
...
Графически - это дерево...

Подумав немного можно предложить такую модель:
Все Персоны хранить в таблице Персонал, где иметь поле начальник со значениями: начальник0, начальник1, начальник2
Завести дополнительные таблицы начальник_уровень0,начальник_уровень1,начальник_уровень2,... где и связывать иерархию персон по ID
(можно завести только одну таблицу начальник_уровень, где завести еще поле тип_иерархии:уровень0,уровень1,уровень2)

Но такие модели не предусматривают проверку, что началник0 в иерархии, есть действительно начальник для персон(ы) из уровня 1, а не из 2
(начальник уровня0  НЕ может быть начальником персоны из уровня 2, только для 1(это ДЕРЕВО))

Как все-таки организовать такую модель?


ПС. Можно, конечно, завести разные таблицы для всех персон из разных уровней и затем их связывать - тут ошибок быть не может...

По поводу деревьев на основе БД, см. статьи на rsdn:

http://www.rsdn.ru/article/db/Hierarchy.xml
http://www.rsdn.ru/article/db/Dewey.xml
http://www.rsdn.ru/article/db/db_nav1.xml

mr.DUDA, спасибо, почитал, много интересного, но проблема не решена... думаю дальше...

Предлагаю такое решение. Всю информацию хранить в одной таблице - персонал(id_person, id_per_shef,....) - там где многоточие может быть любая доп информация.  Получается такая структура:
(1, 0,...)
(2, 1,...)
(3, 0,...)
(4, 3,...)
(5, 4,...)
(6, 4,...)
(7, 2,...)
(8, 2,...)

Запись где id_per_shef = 0 - корень. В данном случае имеем 2 корня(2 начальников   ) - 1 и 3 для 1 подчинённый -  2, для 2 - 7 и 8, аналогично можно развернуть всё в другую сторону - для 8 иерархия такая: 2-1, где справа самый большй начальник - бигбосс так сказать.  

Структура достаточно удобная - проверено на практике.

sleep_walker, спасибо,
но в предложенной модели отсутствует

Ну дык это совсем не проблема. Можно добавить 3 поле - уровень:

(1, 0, 1...)
(2, 1, 2...)
(3, 2, 3...)
(4, 2, 3...)

А далее на эту табличку прописать триггер на insert, в котором проверять - если вставляется запись (5, 1, 3...), то смотреть уровень родителя и если уровень вставляемой записи минус уровень родителя = 1, то разрешить транзакцию, иначе отменить... И триггер на update, тоже - если апдейтится поле уровень, то выполнять аналогичную проверку.

sleep_walker, спасибо за предложение...

Но вопрос был Как все-таки организовать такую модель? Использование триггеров это уже "искусственный" fix...

Pankon, реляционные БД потому и реляционные что не имеют поддержки иерархических данных в рамках одной таблицы.