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

Сейчас насущный вопрос:
Сделать релятивную базу в Access по следующей схеме
Нажмите для просмотра прикрепленного файла

1 Как сделать запрос, что бы сохранилась возможность задавать несколько корпусов для одного резистора?
Простой запрос не позволяет этого сделать

Я, конечно, дико извиняюсь... Но что означает слово "сохранилась"? Она уже была? И что означают слова "несколько корпусов для одного резистора"? Альтернативные посадочные места с разными размерами?

В CIS есть возможность добавлять новые записи в БД. При этом можно назначить на одну запись несколько корпусов и несколько УГО.

В CIS можно записать в ячейку несколько корпусов через запятую (запятую по-умолчанию).
Тогда в CIS, в данном поле, появляется выпадающий список с этими самыми корпусами.
Можно сделать запись в таблице Footprint уже с несколькими корпусами.
Я же хочу для каждого значения корпуса иметь одну запись в таблице Footprint, а в таблицу Resistor подставлять эти значения и подставлять столь необходимую запятую.
Внимание вопрос! Позволяет ли Access внутри запроса подставлять эту самую запятую.

Что-то тяжко мне сформулировать свою мысль.

У нас это решается с помощью программирования хранимыми процедурами. Буратино говорил, что в аксессе это все легко. Спросите у него. Впрямую этого не делает ни один сервер.

Oracle позволяет сделать такой финт прямо в запросе, с 11 версии (краем уха слышал).

В Access есть Модули и Скрипты, может с помощью них можно сделать, кто знает?

самое главное ЗАЧЕМ????
ведь каждому номиналу и корпусу соответствует определенный партнамбер производителя, вы работу схемотехнику облегчаете, а менеджеру по закупкам усложняете, нет?
мы сейчас стоим на том же распутье в организации базы данных, но нас сдерживает PDM система, в том что передать в PDM надо именно партнамбер компонента, ну и согласитесь, что потом ручками его туда вколачивать это адский геммор. если вы скажете, что удобство работы схемотехника превыше всего, то наш начальник производства не согласится и будет наверное прав "ваши там файлики и прочее - фигня, без нормально оформленной документации, по которой ваши идеи можно было бы БЕЗ ВАС воспроизвести. без документации это всего лишь файлы".
поэтому будем на каждый номинал, на каждый корпус и прочие параметры компонентов заводить отдельную строку в БД. да БД будет не маленькая, ну а что делать?
в конце концов в CIS довольно удобная система поиска.

Самый простой пример - электролитический выводной конденсатор. Может стоять, может лежать на одном боку, может лежать на другом боку. Будете три партнамбера делать? Вряд ли. Захочется под одной записью провести, а в данном случае это еще и правильно будет. Вот тут и понадобится alternative footprint. Можно еще вспомнить, где понадобится, но это пример наиболее очевидный.

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

Как в том анекдоте: "... на русском форуме вам объяснят, что вы му*ak, и занимаетесь не тем чем нужно".
Здесь мы не будем обсуждать надо это или нет. Есть вопрос, если у вас есть ответ, или дельное, обдуманное предложение - велкам, нет - читаем первое сообщение, там есть ссылка для холиваров.

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

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

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

Хм.. а это идея.
Надо сделать 3 таблицы:
1 Package (r_0805)
2 Footprint (r_0805, r_0805_s, r_0805_l)
3 Resistor

3-ая содержит ссылку на 1-ую, а 1-ая - на 2-ую. Гуд .
Получится ли при этом из CIS создать новый компонент с несколькими футпринтами...

Теперь возникает второй вопрос:
Надо ли создавать отдельные записи для корпуса резистора и конденсатора (r_0805 и с_0805)?

Перестраивайте мышление.
Корпус - это сущность, отдельная от резисторов и конденсаторов.
У нее есть название, например, "0603" (советую, кстати, почитать, как оно там правильно звучит в стандартах, не помню, JEDEC, вроде) и куча других атрибутов.
Поэтому создадите справочник корпусов и будете связывать эти корпуса не с резисторами, а с компонентами
. Это я к тому, что не надо лепить табличку "резисторы". Не обижаетесь? А типы компонентов создадите отдельно.

Мы немножко торопимся. От простого к сложному. Пока это все не укладывается в голове.

Зайдем с другой стороны:
Надо ли создавать отдельные записи для футпринта резистора и конденсатора (r_0805 и с_0805)?
Для Allegro Editor это ведь особо и не нужно.


Про стандарты.
Киньте кто-нибудь данные стандарты, или ссылку.
Еще где то проскакивало про соответствие номера пина и вывода, например для электролита, диода. Тоже хотелось почитать такой стандарт.

имхо, надо. Например, шелкография может быть разной, что полезно.
Кроме того, я для футпринтов использую за основу IPC7351, так там прямо прописано, что резисторы имеют префикс RES, а конденсаторы - CAP.
Считать IPC7351 основой или нет - дело Ваше, с точки зрения БД это фиолетово. Я советую иметь для каждого футпринта в базе несколько наименований и ссылок на стандарты, по которым они именуются.

Таки поделитесь IPC7351. Или он легко доступный?
Какие еще есть стандарты для наименований?

Для Вас - да. Сходите в закрома.
Раньше был, по-моему, IPC-782 (боюсь напутать цифры), в некоторых проектах, возможно, увидите еще такие футпринты. А до того, вроде бы, и не было ничего, кто во что горазд. Он потому и появился.

Префикс в футпринте не имеет значения, все равно он будет надписан импортируемым из схемы. Видел либу, в которой у всех футпринтов вписано REFDES. И работает ведь...
Другое дело, что футпринты резистора и конденсатора реально отличаются. Хотя бы по высоте например. А учитывая, что Аллегро с высотой компонентов очень даже правильно работает, имеет смысл следить за корректностью ее определения в футпринтах. Степени детализации каждый может сам себе придумать. Когда нет гонки, могу и так нарисовать:

Нажмите для просмотра прикрепленного файла

Опять провоцируете? Работать-то будет, но так лучше не делать. Имея префиксы легко классифицировать детальки по группам, а это - очевидный плюс. Например, можно из нескольких групп быстро создать классы в allegro (которые DISCRETE, IC, IO). И этот плюс имеется только при работе с allegro. А ведь есть еще и другие...

По моему, вы оба на разных волнах. И при этом умудряетесь вести диалог.
Uree, мы говорим о названии корпуса (т.е. имени файла), а не о его внутренних свойствах.

Да при чем здесь провокации? Вы говорите о футпринтах, а аргументируете пострением БД. При чем тут одно к другому? Сами постоянно напоминаете чтобы не смешивать понятия, а тут нате вам...

Вопрос: Надо ли создавать отдельные записи для футпринта резистора и конденсатора (r_0805 и с_0805)?

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

Речь идет о футпринтах и что там в этом футпринте нарисовано. Или это уже не так?

"Кроме того, я для футпринтов использую за основу IPC7351" - за основу чего? Названий? Графики? Размеров?

После этого я и написал, что в футпринте указанный префикс не имеет значения. Речь о базе, классификации и т.п. не шла. Исключительно о содержании текста "на слое" Components -> RefDes -> Silkscreen/Assembly_Top/Bottom.

А если говорить о названиях корпусов, я обоими руками рекомендую пользоваться IPC. Очень удобно. И в своих либах понятно, что в каком файле содержится, и получив вдруг проект со стороны тоже не надо обмерять каждый корпус, чтобы понять его особенности. Ибо максимум инфы уже в названии заложено.

Uree
Не горячитесь.
Почитайте название топика.


Всего.

Совершенно верно.
Полное взаимопонимание достигнуто?

По названиям да. Только тогда не смешивайте названия корпусов(футпринтов), префиксы символов на схемах и шелкографию на плате Это все разные вещи и в разных местах процесса проектирования расположены.

Вы опять!?

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

Кстати, Вы IPC с наименованиями корпусов уже нашли? В случае если нет, я выкладываю.

Я надеялся, что там уже все обсудили.


Спасибо.

Итак, согласно моему видению, есть 3 таблицы:
1 Package (r_0805)
2 Footprint (r_0805, r_0805_s, r_0805_l)
3 Resistor
Выяснили, что футпринты должны быть раздельными, например, для резистора и конденсатора, значит и Packag'ы должны быть раздельными - r_0805 и с_0805 (что бы оставаться в рамках Access, и не делать нереальных запросов).
А вот теперь скажите, vitan, есть ли здесь подводный камень, где он, и как его обойти.

Этого мы не выяснили. В чем нереальность запросов? Повторяю, корпус (если только он один, не готов сказать по резисторам, предлагаю пример для микросхемы - TQFP-100 - туда миллион разных микросхем можно записать и стандарт на него где-то есть) должен быть один.
Про камень скажу, когда с этим разберемся. Ну и про таблицу резисторов напоминаю на будущее.

Помимо предложенного Uree файлика рекомендую скачать оригинальный текст, ну и применять калькулятор. Вроде бы, это он (программа на компьютере) является исходным документом, формирующим правила именования.
Кстати, по нему же именуются и падстеки, я тут недавно пытался докопаться до сути, но как-то не получилось...

нормальный ответ, соглашусь, что возможно иметь альтернативный футпринт и в реальности не один, об этом не подумал.

так и какое решение для этого? ну это в рамках "от простого к сложному".

Как создать альтернативные футпринты? Я не знаю, как там с простым и сложным, но у нас есть поле ALT_SYMBOLS, значение которого формируется из списка футпринтов компонента путем объединения их в строку через запятую с помощью хранимой процедуры.

Собственно попробовал сделать эти 3 таблицы.
В Footprint хранится уже готовый список, а не формируется из отдельных записей. Как то я сразу не подумал, что это те же яйца, только с дополнительной таблицей.

Получается, надо делать процедурку. Как ее сделать в Access?

Специально для vitan:

Сегодня на баше прочитал .
Не создавай излишних сущностей, ибо грех это великий.

Все, минутка офтопа закончена, чур не развивать его дальше.

Отнюдь. В названии присутствуют слова "от простого к сложному"? Так вот, несозданием сущностей Вы до сложного не дойдете, уж поверьте.
И никакого офтопа.

Полуофф, по поводу корпусов резисторов и конденсаторов - они должны быть разные.
Я не знаю как написано в стандарте IPC-7532(его нет в закромах), но в старом IPC-SM-782A требования к контактным площадкам резисторов и конденсаторов разные!
Нажмите для просмотра прикрепленного файла Нажмите для просмотра прикрепленного файла

снова практический вопрос.
итак решили как делать, как хранить и прочие заморочки сложные по-началу для понимания .
пошли дальше, организация самой БД в Access.
есть у нас (нет ну как есть? мы так думаем, что будет) несколько таблиц: резисторы, конденсаторы, коннекторы, микросхемы, транзисторы и т.д....
есть таблица коннекторы, в которой определенный набор параметров (type, pin count, pitch, ... , schematic, footprint, DEVICE, descpription, ...).
разъемы, ни для кого не секрет делятся на типы (коаксиальный, цилиндрический, прямоугольный, D-Sub, винтовые клеммы и проч...).
хотелось все это держать в одной таблице, ну по-крайней мере чтобы CIS видел в одной таблице. пытаюсь сделать с помощью мастера подстановок перечень возможных типов (ну по сути не важно что именно, можно корпуса для резисторов, микросхем и проч) в CIS я вижу ID строки.

как это побороть?

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

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

Ну не дошли мы до этого. Не вижу я удобства в одной таблице.
И ваще, что-то как-то в Access не делается по-быстрому нормальная релятивная база.
Хотите серьезно и надолго - поднимайте сервак с нормальной базой, продумывайте структуру, иерархию, пишите доп. тулзовины.
Вощем, я остыл к этой теме, пользуюсь тем, что есть и особо не парюсь.

Это от того что ваша база (реальная или гипотетически возможная) спроектирована до уровня на котором вносятся данные в систему, а этап с анализом и выборкой информации пока остается "за кадром". Как только понадобится вынимать что-то из БД, вот тогда любое излишнее дробление вылазит боком.
Сама суть связывания Альтиума с внешними таблицами/базой данных сводится к тому, чтобы тиражировать записи в таблицах вместо того чтобы дублировать модели компонентов. При этом (и это на мой взгляд самое важное) с конкретным компонентом и его номиналом связывается уникальный идентификатор/ключ. Вот это сила.


Не устаю повторять: Акцесс не хуже, всех остальных инструментов ,все у него есть и даже возможность строить настоящие клиент-серверные решения. Более того, я бы ввел изучения этой программы в первые классы школ. Это удивительная прога ,многогранная и гибкая. С момента выхода "1997" версии ,кто-то там в Микрософте уволился из ведущих разработчиков или менеджеров этой платформы, но даже последние версии еще вполне работоспособны.
Я лично пользуюсь Access как инструментом для решения широкого круга задач, вот например в последний раз строил систему, которая проанализировала слова в даташите на АТМегу32Ю, руководстве на компилятор ИАР и юзер мануале для сликедитора. В качестве результата имею словарь с показателями плотности слов, что-то типа "дисперсии" и алфавитными сортировками, как отдельно по документам/главам/абзацам строкам так и по группе документов из списка. За чашкой чая, и я ведь не программист как бэ.


Все зависит от целей которые вы ставите перед собой: если эти цели "не парится" то это одно ,если вам нужен инструмент, то это другое.



Основная таблица/хранилище должна содержать 5полей:
ID Длинное целое
ParentID Длинное целое
Name Текстовый255
Library Ref Текстовый50
Footprint Ref Текстовый50

Только этого уже достаточно чтобы построить дерево компонентов.

Если предприятию необходимо что-то кроме того что уже есть - добавить функциональную таблицу(Ы) и связаться по ID
Library Ref , Footprint Ref можно заменить внешними ключами с ссылкой на справочник, но в моем случае достаточно и этого.
Футпринты и УГО хранить в одних файлах а не создавать по 10 штук для каждого типа полупроводника. Вот тогда будет и красота на схемах и порядок на платах.
---
Это вы еще не добрались до перебросов в солидворкс плат ,вот там без правильной БД и обвяза стройного ваще нефиг делать.

Дежавю...
Вторую картинку как-то я уже комментировал, похоже.
Не поленюсь и еще раз.
Такая классификация некорректна, ибо она сделана сразу по нескольким признакам.
Корректной считаю, например, такую, как на моей картинке.
Вообще мое мнение по этому поводу с тех пор не изменилось, в том топике все подробно расписано.
Просто хочу предостеречь новичков...

Да, был у нас курс, что то вроде "Программирование .... для магистров". Вроде пытались привить любовь к VB for App. Вот де вам Excell, а вот вам и VB, а теперь мы можем делать с ячейками все, что захотим. Но я удачно отмазался от VB и cдал итоговою работу на VHDL. Не лежит душа к бэйсику, не приживается. Вроде много можно сделать, но как то все кривовато. Может я не умею его готовить? (это риторический вопрос, не надо на него отвечать )

Вот скажите, Буратино, если все возможно в Access, почему вы молчите и не подскажете, как решить задачу описанную в посте №№3-5?


Ключевая фраза. Ответ - не надо. Думал можно малой кровью сделать для себя немножко поудобнее, но ...

Я работаю на маленьком предприятии и большой практики по интеграции работы конструктора и моей пока не наблюдается, однако уже сейчас все спецификации (разделы оной) и перечня я готовлю из своих баз. На повестке дня переброс дизайна готовой платы в Солид, и тут не менее актуальна четкая система и уникальные идентификаторы компонентов. Такая классификация создана именно под эти цели ,других пока не вижу. Более того если даже и увижу то изначально система ориентирована на возможность перестройки и перекомпоновки иерархий, однако в таком случае потеряется связь PCB проектов. Получается как бы две формы хранения моделей для Альтиума: одна это связки моделей в компонент, а другая это базирование компонента в иерархии классификаций. Вот в моем случае первая форма остается тождественной любым перемещениям компонента, а вторая, естественно, страдает. В Вашем случае (с разнесенными библиотеками и отсутствием иерархии и сортировки в группе) классификация есть чисто номинально, формально, но ее нет для цепочек конструктор-конструктор или коструктор-склад. Поправьте меня если я ошибаюсь.


Да при чем тут бейсик? Фишка Accessa не в VBA, а в SQL + DAO(ADO) . И нет никакой разницы что бейсик что С++, ибо используются методы и свойства объектной модели по доступу к данным из рел. хранилищ. А популярен акцесс в силу своей дружественности и простоты. Немаловажным является поддержка макросов , конструкторов, "быстрых" форм и встроенного генератора отчетов. Ну и VBA нельзя сбрасывать со счетов, чес слово все там для своего времени четка.



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


Внимательно перечитайте посты вверх: согласитесь, я Вас ни в коем случае не отговариваю от такого решения, я лишь обратил внимание на то, что Microsoft Access тут ни при чем.

Я что-то никак в толк не возьму: чем именно такая классификация помогает перебрасывать в солид, почему другая не поможет, и вообще, как эти вещи связаны?


Если за идентификаторы компонентов берется то, что у Вас на картинках в поле NAME, то ясно дело, потеряется. Потому что там, извините, бардак. Чтобы такого не было, надо отличать компоненты по неким уникальным ID. Вы тоже об этом постоянно говорите, но, похоже, Вы думаете, что это ID должно быть простым числом. Если так (нет - поправьте), то советую применять для компонентов не числа, а т.н. корпоративный партнамбер. В качестве него смело можно использовать код заказа компонента из даташита. Этот вопрос уже обсуждался где-то в интернете несколько раз, в т.ч. и здесь, так вот: вряд ли кому-то удастся найти два разных компонента с одинаковым кодом заказа. И это среди всего многообразия. Но я, тем не менее, советую для кодов заказа вести отдельную колонку в таблице. Почему - расскажу, если кому-то это надо.


Я вспомнил, о чем мы давно говорили. Вы говорили, что в базе надо хранить компоненты в порядке возрастания параметров, чтобы в КД потом писать. Так?
Я тогда уже говорил, что сортировка выполняется совершенно спокойно путем извлечения в запросе столбца со значением емкости, к примеру. При этом никакие цепочки не рвутся, и ГОСТ не нарушается.

мне вот не совсем понятен момент именно "когда в БД НАДО заводить новый компонент"?
просто кто решает ЧТО надо внести в БД, а что НЕНАДО? тут возникает роль библиотекаря (ну или того, кто внятно может дать ответ на те или иные вопросы по организации самой БД).
или например ткнуть схемотехника носом в компонент, который он не смог найти и попытался организовать запрос на добавление компонента в БД.

все эти таблицы и прочие дела это на мой взгляд (правда не самый опытный взгляд) дело техники, хотя наверное если все организовать в одной таблице, то при правильной организации самой таблицы и организации пользователей в какой-то момент все будет очень даже удобно всем ролям пользователей БД.

у нас планируется идентификация компонентов по внутреннему ID, который будет в первую очередь заводиться в БД PDM, после этого, уже с помощью организационных моментов, будет заведен компонент в БД Allegro (схемотехническую). схемотехник конечно может использовать любые библиотеки и компоненты, до момента сдачи проекта в PDM систему, во время сдачи проекта ему предложится верифицировать все компоненты.

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

то vitan: не могли бы вы скинуть на емайл просто шаблоны таблицы для понимания, я так понимаю что у вас организовано не в акцессе? но суть я думаю будет ясна. не хочется наступать на грабли dead_cell(шабака)mail.ru

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


Правильно, пусть используют, что хотят, но потом верифицируют. Я сам именно так и работаю.
Однако, мне непонятно, зачем городить две разных БД. Какая у Вас PDM?


Этим должен заниматься не библиотекарь, а архитектор системы, которому совершенно все равно, сколько там таблиц.


В топике из раздела альтиума я приводил примерную структуру, посмотрите там, сейчас мне совсем не до того...

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


Так и я Вам отвечал уже что не получится у вас алфавитно отсортировать номиналы у тех-же резисторов или конденсаторов, судите сами:
Вот например резисторы в алфавитном порядке:

0.47R
0R
1.2k
1.5k
100
100k
10k
10R
150
15k
180
1k
1M
1R
2.2k
2.7k
200
20R
220
220k
22k
22R
25R
270
2k
2R
3.3k
33k
33R
3M3
4.7
4.7k
40k
470
470k
47k
47R
540
680k
68R
820


Вот в порядке номиналов:

0R
0.47R
1R
2R
4.7
10R
20R
22R
25R
33R
47R
68R
100
150
180
200
220
270
470
540
820
1k
2k
1.2k
1.5k
2.2k
2.7k
3.3k
4.7k
10k
15k
22k
33k
40k
47k
100k
220k
470k
680k
1M
3M3

Хм. Сами же привели пример, что после небольшого изменения классификаци у Вас потеряется связь с PCB. Если это правильно, то без комментариев.


1. Я нигде говорил, что буду сортировать номиналы по алфавиту.
2. То, что Вы привели - не номиналы. Номиналы - это числа. А у Вас смесь из букв и цифр. Это - кодировка номиналов. Типы кодировок, кстати могут быть разные.
3. Если Вам очень хочется сортировать детали в порядке увеличения номиналов, то это делается выведением столбца с _числами_ рядом и сортировкой.
4. Если деталь записывается в список в виде кода заказа (импортная, например), то правило сортировки по номиналу из ГОСТа можно прилепить к этой ситуации с очень большой натяжкой. Гораздо естественне сортировать текст кода заказа, это абсолютно ни у кого проблем не вызывает (видимо, кроме Вас).
5. Подмешивать во внутренний идентификатор путь из классификатора (как на картинке) считаю неверным хотя бы по причине того, что такой идентификатор вряд ли удастся передать в PCB (из-за слешей и длинного имени).
В общем, не путайте понятия партнамбера, номинала и т.п. и все будет хорошо.

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

PDM Windchill, как раз тут достался классификатор компонентов по Windchill'у, мозгуемс.

А вот зачем нужна связь базы с готовой платой? После того как я "стянул" компонент на схему и перебросил на PCB мне все равно что там в базе и как он теперь называется. Получается что на этом функции библиотеки кончаются. Если к библиотеке присоед. другие базы то конечно же необходимо обеспечить целостность баз и при смене ID менять внешние ключи в связанных таблицах.

1,2,3,4 Хотите вести абсолютно лишнее поле с номиналом в виде цифр - ведите. Хотите иметь перечни/спецификации с кодами заказа вместо номиналов - пожалуйста, а я пока все же останусь при своем мнении. Ведь все получается естественно и органично: ID служит и для построения дерева компонентов и для сортировок внутри группы.
Да, и ID и мой самопальный партнамбер могут смениться в базе по отношению к готовым проектам, но я пока не вкуриваю где такая связь может пригодиться.

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

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

это я просто для себя, как у кого происходит обмен информацией между ECAD <-> MCAD

ну а как еще может происходить? один удалил, а другой поставил.

а если компонентов на плате где нить к 500? и заменять надо с 10-ток?

хотя это к БД косвенное отношение.

Связь с базой нужна всегда.
Разработка изделия состоит не только в рисовании схемы. Если Вам действительно нужно ускорить разработку и избавиться от ошибок, то надо подключать к базе как можно большее число работников. У них будут разные САПРы (у некоторых вообще не будет, только ексель, например - закупщики), но источник данных должен быть единым и актуальным для всех.
Не все САПРы обладают возможностями по работе с БД, но это другой вопрос.
Конкретный пример с заменой сотни элементов на аналоги из базы в плате Вас не убеждает, что ли?


Это пока. Другой пример из жизни: Вам потребовалось через год сделать редизайн одной платы с заменой компонентов или объединением нескольких каналов на рассыпухе в одну плисину (к примеру). За год у Вас понимание изменилось и Вы поменяли структуру библиотек (к примеру). Т.к. Вы фанат ГОСТа, то Вы перенумеруете все позиционные обозначения заново на схеме, добавите плисину и удалите 30 корпусов рассыпухи. Сроки сжатые и Вам хочется остальную разводку не трогать. У Вас есть автоматизация, Вы генерите перечни из базы, но сейчас Вы этого сделать уже не сможете: партнамберы уже поменялись.
Не убеждает?


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

А что это такое?

Нажмите для просмотра прикрепленного файла

по сути, теперь уже возложили на программиста написание проги под заведение нового компонента в БД Access и верификацию нашей БД с БД PDM. пока что по другому не видится. другое дело как оно будет в Access'е одной таблицей с кучей параметров, от всех классов или отдельными таблицами? ну это тоже постараемся возложить на программиста, только бы Allegro потянул.

и снова вопрос к специалистам по CIS.
во решились мы например вести БД в Access. решили вести в одной отдельной таблице, где будет много параметров у каждого класса компонентов, какие-то будут пересекаться между собой, какие-то будут сугубо индивидуальные для каждого класса , соответственно для каждого класса свои (нужные) параметры будут заполняться, а параметры других классов будут пустыми. есть ли возможность в CIS каким то образом не отображать пустые параметры в зависимости от Part Type?
или необходимо тогда вести каждый класс компонентов в отдельной таблице?
параметры и классы см. выше.