Цитата(Hoodwin @ Feb 25 2012, 23:21)

ВП - это вообще документ для сдачи в архив

Для практической деятельности это примерно тоже, что бумажная документация по шаблонам печатной платы. Если кратко, то дефицитка дает информацию о том, каковы минимальные потребности по закупке деталей.
Эмм... ВП она, вроде бы для практической деятельности всю жизнь была... Не понимаю, зачем нужна эта дефицитка, если в ВП черным по белому написано, сколько и чего покупать. И по исполнениям, и на регулировку запас и все прочее. Почему нельзя ее взять и посчитать потребности в закупках-то???
Цитата(Hoodwin @ Feb 25 2012, 23:21)

Многие детали, особенно пассив, для серийного производства приходится закупать катушками (иными упаковками). Либо другая ситуация, когда какой-нибудь специфический разъем можно достать с завода только начиная с некоторого минимального количества. В этих случаях дефицит покрывается сразу на несколько заказов вперед, причем возможно и на несколько проектов сразу, как, скажем, конденсаторы по питанию.
Ну да, обычное дело. Но и тут дефицитка эта как бы ни причем...
Цитата(Hoodwin @ Feb 25 2012, 23:21)

Value при закупках?! Если честно, ни разу об этом не слыхал. Для закупок мы имеем либо пару Manufacturer:Part Number, либо на худой конец Description, точнее специальное поле для заполнения спецификации по ЕСКД, которая отражает общие свойства компонента, по которым его можно запрашивать у поставщиков, например "конденсатор керамический 0603 X7R 0.1uF 25V 10%". В некоторых случаях общение с поставщиками затрудняется, если вместо обобщенного наименования им выдать, скажем, Part Number от MURATA.
Ну дык сами же пишете: 0.1uF. Это разве не value? И разве оно не участвует в закупках?
А... Понял, у Вас это забито еще и в некий доп. дескрипшен. Такие методы хранения информации мы не используем.

Это как минимум дублирование, да еще и формируемое вручную наверняка. Плюс отдельно хочу заметить, что эта параметрическая форма записи не дает гарантии покупки правильного конденсатора (это мы недавно обсуждали уже).
Цитата(Hoodwin @ Feb 25 2012, 23:21)

Меня семантика Value устраивает на 100%. Скорее интересно, как это обобщить на произвольные размерные величины.
А что, с другими не работает, что ли (Вы сразу просто как-то не очень ясно написали)?... Это тоже интересно тогда. Еще кривизна.
Цитата(Hoodwin @ Feb 25 2012, 23:21)

Кривизна софта совсем в другом.

Я как-то назвал таблицу по-русски "Конденсаторы". И она даже появилась в списке таблиц, я все настроил для нее, сохранил конфигурацию, и началось. При попытке снова запустить CIS Configuration Cаpture вылетает. Не переваривает русские буквы в имени таблицы. Не знаю, может в новых версиях что-то изменилось, но в 16.2 так.
О, это я уже и за кривизну перестал считать за годы...

Цитата(Hoodwin @ Feb 25 2012, 23:21)

Так с явным указанием единицы измерения еще большая определенность

Система СИ, конечно, хорошо, но я в Фарадах записывать номиналы не хочу. Например, в машиностроении приняты миллиметры и ставятся без указания "мм". И ничего. По мне так лучше 0.1uF, а не 1e-7 какие-нибудь.
Ну да, я же говорю, в схематике задается. И при экспорте задается. Но никак не в базе, и ни в коем случае не в виде текста типа "156Ом"!
Цитата(Hoodwin @ Feb 25 2012, 23:21)

Я почитывал ту переписку в соседнем форуме в 2010 году про затею сделать некую общественную базу через текстовый data source, распространяемый по http, но идея, боюсь, утопична. если уж делать базу, то не только для целей рисования схем. И это расходится с концепцией read-only свойств. Я уже не говорю, что это все заживет при довольно сильной унификации библиотек УГО, футринтов, моделей MCAD, и т.п., чего на самом деле и в помине нет.
Да, я там чуть ли не в первом посте сказал, что все заглохнет. Но зато там были полезные идеи и для меня тоже. И неважно, что я же их сам и высказывал, в основном.

Без обсуждения они бы не возникли просто.
А что за концепция read-only свойств?
Цитата(Hoodwin @ Feb 25 2012, 23:21)

Да вот я тут думаю, что если уж пошла технология наследования свойств через view, то, может можно вообще все таблицы сверстать в несколько View (вообще один), в которых через Part Type развести иерархию.
Тут я не помогу, лень вспоминать все про CIS. Но применение иерархии и наследования свойств одобряю, конечно. Предупреждаю, что это потребует серьезного программинга для написания клиента. Но оно того стоит.
Цитата(Hoodwin @ Feb 25 2012, 23:21)

А как Вы наполняете базу, если не секрет? Каковы основные принципы? Компонентов же много. Будешь прописывать в базу вообще все, что в природе есть, так жизни не хватит ее наполнить. Будешь наполнять только тем, что на складе есть, так тогда непонятно, что делать, когда хочется в схему ставить новые номиналы. С другой стороны, если вносить про все детали, то можно какой-нибудь скрипт написать, который сразу для всех компонентов создает нужные записи, например, прописывает все резисторы 0603 5% от конкретного производителя в базу, заполняя все поля автоматически. Но скрипт нужно с умом писать уметь, и на него плохо ложатся микросхемы. Но в любом случае, если работать через CIS, то нужен инструмент доступа к базе, который всегда под рукой и простой как молоток. Я даже не представляю пока, на основе чего он должен быть.
Я вношу в базу компоненты, которые юзаю в схемах. Никаких упреждающих компонентов и пачек резисторов не вношу. Обычно все так и работают...
Сами операции по внесению и редактированию делаются в самописаном клиенте. Скриншоты, кстати, из него. Добавление пока сделано в виде виндозного мастера, но грядут улучшения типа копирования на основе и др. Затем компоненты обычно отправляются на проверку соседу. Для этого развернута система workflow и написан процесс. Он исполняется, и если все ок, то проставляет в базе галочку "проверено". Во вьюхи для схематика попадают только такие компоненты, в клиенте видно все. Как-то так.