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

Вобщем чем дальше влез тем дальше вылез :)

Вопрос не в рекурсии, а по нимании, что есть что.
Например рецептуры - это нормы, которые действуют определенное время, т.е. это таблица абстрактных правил, в которых участвуют изделия, сырье, полуфабрикаты в определенной пропорции (количественном отношении). Рецепты ни в коем случае не путать с производством. Производство формирует реальные партии товара, а рецепты - только правила списания товаров при приготовлении изделия/полуфабриката.

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

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

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

По деревьям такой крео
> Есть таблицу с древовидной структурой Tree.
> Поля таблицы Tree:
> ID (целое) - идентификатор объекта
> ParentID (целое) - идентификатор "родителя", если верхний уровень, то 0
> Level (целое) - уровень объекта, самый верхний - 0, делее 1,2....
> Path (строка) - самое интересное :) список идентификаторов ВСЕХ родителей через запятую (например 23,15,46,12). Порядок в списке особо не важен
>
> Запрос пути:
> SELECT .... FROM Tree WHERE FIND_IN_SET(ID,ObjPath) ORDER BY Level
>
> ObjPath - поле Path обекта, путь к котрому надо найти. Если известен только ID объекта, тогда придется сделать два запроса
>
> SELECT @ObjPath:=Path FROM Tree WHERE ID=ObjID;
> SELECT .... FROM Tree WHERE FIND_IN_SET(ID,@ObjPath) ORDER BY Level;
>
> В результате получим таблицу - список родителей начиная с самого верхнего, заканчивая самым последним.

И не следует рассмативать процесс изготовления изделия, как дерево. Достаточно действий над партиями и процессингом, все действия линейные и опывают каждый конкрентый шаг изготовления.
Для каждого преобразования на 1 тип изделия нужно делать акт изготовления. Можно конечно 1 на несколько и можно его вообще пользователю не показывать, но на практике лучше их генерировать, чтобы пользовательно мог все проверить на калькуляторе и увидеть, ведь в конечном счете пользователи должны пользоваться подобным учетным софтом, а не программеры (для опытов, как надо или как не надо делать)...