Не знаю, ничего не получается сформулировать. Да и мысли/идеи теряются. Надеюсь, что Ваш опыт позволит уловить идею и подтолкнуть меня с мёртвой точки.

Сфера - изготовление жалюзей

На входе (бланк заказа типо)
1 поз) Ролет - Rollite - 1500x1500 - 1 шт.
2 поз) Направляющие - AF35 - 5 м - 1 шт.

Надо на выходе
1 поз) Ролет Rollite (баркод 0000000001)
направляющие - АS30 - 1.47 м
касета - Rollite белая - 1.4 м
баласт - баласт 10мм - 1.45 м
ткань - R150 - 1.7 м
и всё остальное
2 поз) Направляющие AF35 (баркод 0000000002)
направляющие - AF35 - 5 м

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

Думается нужно два справочника - иерархический справочник категорий и простой справочник деталей, ссылающихся на справочник категорий.
Иерархический справочник -
КатегорияID ParentID Название Товары? НастоящийID1 0 Ролеты Нет NULL2 1 Роллайт Нет NULL3 1 деколюкс Нет NULL4 2 Направляющие Да NULL5 3 Направляющие Да 4

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

справочник деталей / услуг
ДетальID КатегорияID Название
Ну и сами основные таблицы Заказы, Жалюзи, Комплектации.

Что касается объёмов данных
Самих категорий типа роллайт - 150
Категорий деталей - 90
Самих деталей - 2800
Продано "мегажалюзей" в день - 1000-1900

Если на проектировании вопрос остаётся без ответа - это может означать только два варианта. Надеюсь в моём случае не второй? ;)

Или может для категорий такая таблица лучше?

То что предлагал Латук не уберегает, от ваших (наших) дятлов, хотя для скорости вариант с таблицей отношений действительно хороший...
2. Я ещё задал вопрос о деревянонй таблице с полем "путь" вместо АйДи-ПарентАйДи. Тоже многое что решает. Но не знаю на что могу натолкнуться...
3. То что описано в "процесс" ведёт к тому, что в таблице blindsets помимо ДеталькаАйДи, надо ещё КатегорияДеталькиАйДи - а как же тогда нормализация?
4. И вооще хотелось бы чтоб сказал хто-нибудь что-нибудь, имеющий знаний побольше чем я, которой слова MS Access, индекс, реляционная база данных первый раз в жизни только этой весной услышал...

А несколько групп в изделиях - это что?

Не знаю правильно я догадался и понял, но вопрос такой
какие минусы втом чтобы дерево разделить на уровни (в моём случае таблица Groups) и хранить всё в одном справочнике, вместо Справочник1-СправочникN ?

Это если запись является ссылкой на настоящую запись. Например, "настоящия" категория - шурупы (айди = 1). Эти шурупы входят как дети во многие изделия (категории изделий), но как детей я ввожу (думаю вводить) новые категории у которых реалайди=1 (то есть в ролт детей будут выступать ссылки на "настоящую" категорию). Чтобы проще отличать есть таблица групп категорий - группа "виды жалюзей", "категории товаров", "ссылки"... Соответсвенно у категории шуропов GroupID будет "Категория товаров", а у остальных - "ссылка".

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

потомо что Быкиспростая деталь может быть оформлена и продана, как законное изделие (как самостоятельная жалюзя). То есть получить свой "паспорт" и баркод может как и мегажалюзь из 100-а составляющих, так и элементарная деталь (Направляющие).то есть сделать справочник "категории изделий" - было фактичесуки продублировать справочник товаров, плюс добисать в него теже товары объеденённые в "сборочные листы".


----------------------------------------------------------
ЗЫ: Избавиться может и можно. Я потому здесь и спрашиваю совет как лучше сделать; я не защищаю некую мною разработанную новую методу.

miksoftМожно назвать и сборочный лист. Но связей несколько, т.к. есть "Сборочный лист №1", в него входит шуруп, есть "Сборочный лист №2" в него входит тот же шуруп. Чтобы не вводить два шурупа, я добавил поля RealID (то есть одна запись в сборочном листе Нр.1 - это шуруп, а в сборочном листе Нр.2 - это ссылка на шуруп). Если связи вынести в отдельную таблицу, тогда эта заморочка отпадает. пожалуй всё-таки так и надо далать.

BULK INSERT...технолог рисует темплэйты - создает экземпляры иерархического каскада AGGREGATE-ASSEMBLY и указывает количество... PARTS в тэмплейтах не надо, их укажит опертор при вводе заказа. То еть в темплэйте должна быть только AGGREGATE(1)-КРАСКА-ХХХ-1л. А оператор уже укажит (выберет из справочника) синяя PANTONE 7888R-88.
Связи вы предлагаете вынести в отдельную таблицу или нет? Если нет то как быть с тем что сказано выше (вторая связь по RealID)?

модЭто я думал вынести в отдельную таблицу (AйДи-АйдиАтрибута-ЗначениеАтрибута). Чтобы когда в голову придёт разгрупировать на (круглое, холодное, мягкое, мокрое) проще было изменять/дополнять атрибуты. Но это отдельная тема.

Да во многих програмах именно так, но потому они мне и не подходят. Например ролетов есть 30 видов (Decolux, Elegence...), тканей для ролетов есть 650 цветов (артикулов). По вашему надо сделать 30*650 темплэйтов?
По тому я и хочу придумать (и спрашиваю как это лучше сделать), чтобы было 30 темплейтов с указанием сосьовляющих просто "ткань". А оператор уже указывал бы какая имено ткань.

ЗЫ
proposed amendment1 технолог составляет темплейты указывая номенклатуру составляющих
2 оператор выбирает определенный темплейт и заполняет количествоМне надо наоборот
1 технолог составляет темплейты указывая количество и ктегорию(?) составляющих
2 оператор выбирает определенный темплейт и указывает номенклатуру

Браво!
только я группу аля "33456-990-99 - TEXTILE_DELUXE" называл "категории товаров", щас перварю и буду пробовать

Уточнения (если вас не затруднит)

1)--значит два дерева...половина дерева технологу
так всё таки два или одно поделённое?

2) Группы (условно группы) "Делюксы-елегансы-вертикальные" и "ткани-шлёпки-зашлёпки" в одно дерево или в разные?

3) 33456-990-99 - TEXTILE_DELUXE и REAL_M...SORTED_&_FLOAT находятся в одном дереве (я правильно понял?). REAL_M...SORTED_&_FLOAT ещё используются для елегансов зачит нужна новая объеденяющая группа TEXTILE_ELEGANCE, а REAL_M...SORTED_&_FLOAT будут иметь по нескольку родителей. Как лучше делать? а) деревянный справочник с ПарентАйДи и РеалАйДи, б) деревянный справочник с вынесенными связями в отдельную таблицу?