Компания выпускает ИЗДЕЛИЯ.
ИЗДЕЛИЕ состоит из большого числа компонентов - 10000-15000
Туда входят сборочные единицы(производства компании) - уровень вложенности до 10-12, детали и покупные изделия
Сборочные единицы 50% разрабатываются заново для каждого изделия, 50% берутся из ранее разработанных.
Сейчас организовано так
Таблица MAIN - сборочные единицы и детали в неструктурированном порядке - типа общий каталог
Таблица MAIN1 - описание конкретных ИЗДЕЛИЙ, где содержится точная информация о составе(дереве) ИЗДЕЛИЯ с его полной структурой.
связь по id компонента
Пока это было только для технологов - это работало норм. Сейчас планируется расширение функций и подключение к базе с таблицами конструкторского отдела. Они будут работать не в Аксе, а через VBA модуль в программе CATIA
ВОПРОС - Как организовать правильное (оптимальное) использование сборочных единиц разработанных ранее в новых проектах.
Примечание 1- уникальность состава сборочной единицы естественно обеспечивается, при изменении состава единицы хоть на 1 винт - это уже новая сборочная единица.
вижу 2 варианта
1) получать данные о структуре сборки из табл MAIN1(брать из какого-то уже выполненного изделия) и при необходимости копировать их в новый проект.
2) создать промежуточную таблицу, связанную с MAIN, и содержащую информацию о составе сборочных единиц
Примечание 2 Хранить точную структуру сборочных единиц в MAIN(общем каталоге) не представляется возможным, так как одна и та же сборочная единица может входить в десятки или сотни вышестоящих сборочных единиц с разным уровнем вложенности.
Вопрос локальный, я полагаю что не стоит идти сильно вглубь и вширь всей базы.....

ROIОднозначного ответа вы не получите.

Да его и не существует наверное, однозначного-то...
Ну хоть какой-нибудь бы

Пока склоняюсь к доп таблице со структурой сборок.....
В модуле технологов вообще ничего менять не придется, а поддерживать уникальность состава сборки так ИМХО проще и надежней....

ЛапухХотя довольно прикольно читать, как ТС не может внятно объяснить, а помогальщики не могут внятно подсказать.

Ну кому непонятно..... тот может и не отвечать
Вот Jossу, Idfanatу, vmagу точно все понятно и их ответы-советы все по существу)

Слегка сумбурно просто потому, что на данный момент в конторе нет четкой концепции документооборота, на данный момент ее просто никакой нет, и я собственно ее и создаю сейчас.
В планах стоит создавать электронную структуру изделий, хранить ее в базе данных и работать в дальнейшем с ней. Чертежи - что бумажные, что файлами .CATDrawing - совсем отдельная история, с кучей своих заморочек, и поэтому сейчас я рассматриваю только 3D модели сборок и самих деталей. Понимаю, что есть хороший выход - купить готовую PLM(PDM) и внедрить ее. На то что бы так не поступать есть множество причин, и они все не относятся к данной теме.
И собственно я колеблюсь между 2-мя направлениями
1) Изменения в сборке(единице номенклатуры с уникальным номером) не допускаются, при необходимости внести изменения создается новая сборка со своим номером(номером версии). Естественно присутствует процедура согласования/информирования всех необходимых лиц. После выполнения проекта все не вошедшие в него промежуточные версии сборки ( по желанию конструкторского отдела) выводятся из номенклатуры и файлы удаляются. История внесения изменений хранится в базе в текстовом виде.
В этом случае отдельная таблица со структурой сборок не нужна- можно найти структуру выбранной сборки в таблице с реализованными проектами и использовать ее. Еще плюс - на каждую сборку в номенклатуре обязательно есть свой единственный файл .CATProduct, точно ее описывающий, вся архитектура сборки хранится не только в базе, но и в этом файле.
Минус - даже если убрать или добавить 1 шайбу - требуется создать новый файл головной сборки. Но это легко реализуется программными методами из базы.
2) Изменения в сборке допускаются, структура основной сборки хранится в отдельной таблице - допустим SBORKI. Каждое изменение оформляется/согласовывается и хранится с указанием его применяемости. Именно так и был организован старый советский документооборот. Но так было сделано ИМХО потому, что основой был бумажный чертеж. Создать компьютерный документ, описывающий структуру сборки (типа файла .CATProduct) тогда просто не было возможности.
При этом у нас теряется уникальность файла сборки-нельзя открыть структуру из SBORKI и использовать ее. Надо обязательно поднимать всю историю изменений по всему дереву сборки. Избежать создания нового файла сборки все равно не получается, придется хранить и файл со структурой основной сборки, и файлы с реальной структурой, реализованной в проектах. Рано или поздно, когда изменений будет больше какого-т количества, все равно придется создать новую основную сборку и хранить и ее файл.
В общем я пока не определился.....
несколько дней назад думалось про создание доп таблицы SBORKI
на данный момент склоняюсь к варианту по п1, без нее....
Думаю-соображаю....

Лапух
Может я тоже так хочу, типа научиться видеть суть вещей, но чёй та не пойму чего вы поняли и чего вам подсказали существенного.
Толцытеся.... и отворится вам!

ldfanate Теоретически можно до последней гайки и шайбы - но такое не всегда нужно в эксплуатации, поэтому бывает разузловывают какраз до блочных заменяемых Изделий. А сбоку join-ом ваши нынешние таблицы. Избыточность только добавит надёжности, раз у вас там настолько сложное производство.
Сейчас, в табл MAIN1 как раз и хранится полная разузловка уже выпущенных изделий, до последней шайбы, реализованная по древесной структуре.

code OWN sernn codever qt
151 145 1 59 1
152 146 1 60 1
153 146 1 61 1

Типа так
Code - код текущей записи в MAIN1
OWN - код вышестоящей записи из MAIN1
sernn - код изделия
codever - код детали(сборки) из основного каталога MAIN
qt - количество

ПЕНСИОНЕРКА мы хранили только уникальные строки по КУДА(код сборки)+ЧТО+СКОЛЬКО без привязки к изделию
остальное получали расчетно, например

А вот этого уже не понял я.....

ПЕНСИОНЕРКАSerg197311,

в вашем исполнении я не поняла, что есть количество
- количество в текущей сборке

ldfanate
Такой вариант видится наиболее надёжным :).
Вот и я пока к нему склоняюсь......

Я в таблице храню только количества деталей/сборок в вышестоящей сборке. Если надо посчитать винты такие-то в изделии или в сборке такой-то - это делаю функцией на vba.