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

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

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

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


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


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

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

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

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

Сообщение отредактировал lazarev andrey - Aug 8 2011, 06:26

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

в такой ситуации нужно иерархию вести в одной таблице а все основные классы разбросать по отдельным таблицам со своими спец. полями. Либо все данные по всем классам хранить в одной таблице у который будет всего 4 поля:
первое: идентификатор типа компонентов(класса компонентов)
второе: номер строки
3е: имя поля
4е: значение
Если нужно например достать из базы транзисторы биполярные: вынимаются из такой таблицы все строки с идентификатором типа "транзистор биполярный", переворачиваются перекрестным запросом в таблицу, сортируются по номеру строки. Таким образом даже имея очень разнородные классы компонентов с разным числом полей, мы храним все в одной таблице без пустых значений. Таким образом хранят отчеты в налоговой. Отчеты разные и кол-во информационных полей для каждого конкретного отчета разное. Вот чтоб не плодить тысячи таблиц ,все сваливают в одну узкую но длинную таблицу ,из которой потом "на лету" запросами/курсорами вынимают данные.