Здраствуйте!

Не могли бы посоветовать как лучше хранить данные по сложной иерархии. Опишу облость по форме.

Описание:
Левая часть формы:
Комплекс - содержит набор задач и комплексов
Задача - конечный элемент иерархии

Правая часть формы: При выборе элемента из дерева (слева) выводится информация:
1. для самого элемента в целом
2. для каждого этапа по элементу (строго 4 этапа)

При выборе определенного этапа выводятся процедуры для этого этапа

Пока сделал следующим оброазом:

Иерархия по комплексам и задачам в таблице Tasks. Используется фиктивное значение 0 id_parant для корня. а дальше id_parant в соответсвии с иерархией.

Информация по комплексу или задачи в целом для 4 этапов и для каждого этапа в таблице ModelTasks.

Информация по процедуре для каждого определенного! этапа комплекса или задачи в таблице ModelProcedures.

Таблицы ...PlannedParams для хранения истории по параметрам, параметры со временем изменяются.

Appointments ( только для процедур!) - назначенные рабочие на процедуру, так же там же хранится истоия изменения.

Вопросы:
1. На сколько это граммотно?
2. Стоит ли использовать механизмы хранения иерархии, база не большая: AdjacencyList, Nested Sets?
3. Смущает похожесть таблиц ...PlannedParams и некоторых парметров в ModelProcedures и ModelTasks.

пс: это для моего диплома, по которому защита уже через 3 месяца)

плановые параметры для задач и комплексов могут отличаться в большую сторону чем срок выполнения всех их процедур, из-за этого надо хранить плановые параметры и для задач и комплексов.

:)

_мод Kostelesплановые параметры для задач и комплексов могут отличаться в большую сторону чем срок выполнения всех их процедур, из-за этого надо хранить плановые параметры и для задач и комплексов.
Сие очень странно. Но если итак, то надо просто вводить фиктивные процедуры - модель работает.
Так кстати и во всех программах по управлению проектом. можно планировать снизу вверх и вниз. При планирование снизу автоматически определяются псевдо задачи (комплексы и задачи); при планирование сверху определяютяся разки вложенных задач...

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

_мод Kostelesпри планирование сверху определяютяся разки вложенных задач...
Поскольку процедуры могут перекрываться по срокам (т.е. быть параллельными), то при планировании сверху сначала вводится фиктивная процедура на весь срок задачи, этапа...

в данном случае процедуры строго параллельны у задач и комплексов - обусловленно тем, что результат одних является входными параметрами для других..

Относительно только одного этапа задачи и комплексы принадлежащие одному комплексу могут идти параллельно

Относительно всех этапов есть два пути, который определяется для проекта при создание:
1. пока все задачи и комплексы этапа полностью не выполненны следущий этап для них не начинается. - последовательное проектирование.
2. следущий этап для задачи и комплекса начинается сразу после завершения этапа данной задачи или данного комплекса. - сопараллельное проектирование