Serg197311,

Смотри, у тебя есть единый каталог (таблица CATALOG) номенклатурных единиц из которых собирается готовое изделие. В этот каталог входят такие изделия как болты и гайки, они неделимые. Так же есть изделия, которые собираются из других изделий, как неделимых так и таких-же сборных, они так-же входят в каталог. Для того, чтобы знать состав составного изделия нам нужна таблица с детализацией (DETAILS).
Чтобы такое реализовать минимально нужна такая структура:
Таблица CATALOG:
cat_id - уникальный код изделия (первичный ключ)
cat_name - наименование изделия
cat_type - тип изделия (составное изделие или простое)
Таблица DETAILS:
det_id - уникальный код строки (первичный ключ) ' Можно и без этого поля обойтись взяв за первичный ключ связку owner_id + det_id это зависит от того, веришь ли ты в составные ключи или считаешь их дьявольским изобретением :)
owner_id - код (cat_id) составного изделия из таблицы CATALOG
det_id - код (cat_id) изделия из таблицы CATALOG 'det_id так же может ссылаться на составное изделие
quantity - количество det_id входящих в состав owner_id

Я не делал поля для указания вышестоящей сборки, для того, чтобы построить дерево оно не обязательно - достаточно пройтись запросом в котором указать WHERE cat_type="составное" и получить список всех составных изделий входящих в это конкретное составное изделие и их состав.

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

Serg197311Пока больше склоняюсь к тому, что бы хранить структуру сборки в таблице где хранится вся структура изделия.... выше я детально описывал.....
Ох, чую как ты себе геморрой обеспечиваешь такой организацией БД.

Serg197311Вот я и пытаюсь сообразить - какой именно?
Запихивая в одну таблицу состав конечного изделия и состав составного изделия ты лишаешь себя гибкости. Завтра тебе предложат подключить к системе ещё кладовщиков, сметчиков и тогда тебе придётся переделывать архитектуру БД, а это геморрой.

Serg197311Итого для получения полной структуры сборки из details придется делать еще одну, временную, таблицу со своими уникальными кодами..... так что ли?
Какие коды?
Зачем делать ещё одну таблицу, если все данные по всем составным изделиям есть в таблице Details? Ты просто делаешь несколько запросов и получаешь состав каждого составного изделия. Если есть вложенность, то делаешь ещё запросы. А дерево рисуешь по циклу: нашёл составное изделие, получил его список, добавил строки в контрол, который рисует дерево.