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

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

А Вы уверены, что база данных это единственный выход в данном случае?

Ок. Больше не вмешиваюсь.

Лично я - уверен.
По сути можно использовать не базы данных а например таблицы экселки или даже тупо текстовые файлы с соответствующим драйвером для доступа. Но для связи с другими массивами данных, для экономиии места, для наглядности и простоты работы принято приводить табличную информацию к определенному виду или как еще говорят "нормализовать". В совокупности с необходимостью делать выборки, изменять данные, редактировать ит.п. мы приходим к необходимости использовать те или иные СУБД вместо экселовского файла.
Это деревья, теперь о лесе..

Сейчас я работаю с Альтиумом и самого начала решил перейти к базам и вот почему:
1. Устраняются разночтения и неточности в вариантах наименований, так как я в схему стаскиваю готовый компонент с параметрами и номиналом. Экономится труд так как номинал и упомянутые параметры заполняются единожды, а используются многими и многократно.
2. Есть возможность связать с конкретным компонентом и номиналом - базы и склад, при этом не увеличивается размер библиотек ибо физические УГО и футпринты не дублируются, и представлены как строка в базе данных, при этом появляются возможности редактирования параметров и передачи изменений на схемы и платы.
3. Автоматизация создания конструкторской документации, в том числе перечней и спецификаций.

Без использования базы данных все это если и возможно, то через неправильные места.

"для связи с другими массивами данных" - с какими именно?

1, 2, 3 - это все понятно. Непонятно только почему это обязана быть БД. Design Entry HDL осуществляет доступ к этой инфе непосредственно из текстовых файлов например, в этих же файлах, как атрибут, вписан линк в систему электронного документооборота, указывающий на файл, с перечнем источников данного компонента:

PART_NUMBER | VALUE | TOLERANCE | PART_DESCRIPTION | JEDEC_TYPE | STATUS | INSERTION | VOLTAGE | RATED_CURRENT | RATED_POWER | SCD_LINK
==============}
'RTK-0402F-000R-B' | '0R' | '1%' | 'RES THKFLM 1/AMP SMD 200TC 50V JUMPER 00R SMD0402' | 'RESC_0402' | 'ACTIVE' | 'SMD' | '50V' | '1A' | '0.0625W' | 'http://twdocs.adb.pl/doc/91016'
'RTK-0402F-01R0-B' | '1R' | '1%' | 'RES THKFLM 1/16W SMD 200TC 50V E96 1% 1R0 SMD0402' | 'RESC_0402' | 'ACTIVE' | 'SMD' | '50V' | '1A' | '0.0625W' | 'http://twdocs.adb.pl/doc/91016'
'RTK-0402F-01R2-B' | '1R2' | '1%' | 'RES THKFLM 1/16W SMD 200TC 50V E96 1% 1R2 SMD0402' | 'RESC_0402' | 'ACTIVE' | 'SMD' | '50V' | '1A' | '0.0625W' | 'http://twdocs.adb.pl/doc/91016'
'RTK-0402F-01R3-B' | '1R3' | '1%' | 'RES THKFLM 1/16W SMD 200TC 50V E96 1% 1R3 SMD0402' | 'RESC_0402' | 'ACTIVE' | 'SMD' | '50V' | '1A' | '0.0625W' | 'http://twdocs.adb.pl/doc/91016'
'RTK-0402F-01R5-B' | '1R5' | '1%' | 'RES THKFLM 1/16W SMD 200TC 50V E96 1% 1R5 SMD0402' | 'RESC_0402' | 'ACTIVE' | 'SMD' | '50V' | '1A' | '0.0625W' | 'http://twdocs.adb.pl/doc/91016'
'RTK-0402F-01R6-B' | '1R6' | '1%' | 'RES THKFLM 1/16W SMD 200TC 50V E96 1% 1R6 SMD0402' | 'RESC_0402' | 'ACTIVE' | 'SMD' | '50V' | '1A' | '0.0625W' | 'http://twdocs.adb.pl/doc/91016'
'RTK-0402F-01R8-B' | '1R8' | '1%' | 'RES THKFLM 1/16W SMD 200TC 50V E96 1% 1R8 SMD0402' | 'RESC_0402' | 'ACTIVE' | 'SMD' | '50V' | '1A' | '0.0625W' | 'http://twdocs.adb.pl/doc/91016'
'RTK-0402F-02R0-B' | '2R0' | '1%' | 'RES THKFLM 1/16W SMD 200TC 50V E96 1% 2R0 SMD0402' | 'RESC_0402' | 'ACTIVE' | 'SMD' | '50V' | '1A' | '0.0625W' | 'http://twdocs.adb.pl/doc/91016'
'RTK-0402F-02R2-B' | '2R2' | '1%' | 'RES THKFLM 1/16W SMD 200TC 50V E96 1% 2R2 SMD0402' | 'RESC_0402' | 'ACTIVE' | 'SMD' | '50V' | '1A' | '0.0625W' | 'http://twdocs.adb.pl/doc/91016'
'RTK-0402F-02R4-B' | '2R4' | '1%' | 'RES THKFLM 1/16W SMD 200TC 50V E96 1% 2R4 SMD0402' | 'RESC_0402' | 'ACTIVE' | 'SMD' | '50V' | '1A' | '0.0625W' | 'http://twdocs.adb.pl/doc/91016'
'RTK-0402F-02R7-B' | '2R7' | '1%' | 'RES THKFLM 1/16W SMD 200TC 50V E96 1% 2R7 SMD0402' | 'RESC_0402' | 'ACTIVE' | 'SMD' | '50V' | '1A' | '0.0625W' | 'http://twdocs.adb.pl/doc/91016'
'RTK-0402F-03R0-B' | '3R0' | '1%' | 'RES THKFLM 1/16W SMD 200TC 50V E96 1% 3R0 SMD0402' | 'RESC_0402' | 'ACTIVE' | 'SMD' | '50V' | '1A' | '0.0625W' | 'http://twdocs.adb.pl/doc/91016'
'RTK-0402F-03R3-B' | '3R3' | '1%' | 'RES THKFLM 1/16W SMD 200TC 50V E96 1% 3R3 SMD0402' | 'RESC_0402' | 'ACTIVE' | 'SMD' | '50V' | '1A' | '0.0625W' | 'http://twdocs.adb.pl/doc/91016'
'RTK-0402F-03R6-B' | '3R6' | '1%' | 'RES THKFLM 1/16W SMD 200TC 50V E96 1% 3R6 SMD0402' | 'RESC_0402' | 'ACTIVE' | 'SMD' | '50V' | '1A' | '0.0625W' | 'http://twdocs.adb.pl/doc/91016'
'RTK-0402F-03R9-B' | '3R9' | '1%' | 'RES THKFLM 1/16W SMD 200TC 50V E96 1% 3R9 SMD0402' | 'RESC_0402' | 'ACTIVE' | 'SMD' | '50V' | '1A' | '0.0625W' | 'http://twdocs.adb.pl/doc/91016'
.....

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

[attachment=58142:CropCapt_2_.png]

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


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

Я Вам показал упорядоченные данные по компонентам. Без базы данных. В текстовом файле. С выполнением всех перечисленных Вами условий. Но да, это не осуществимо... Видимо у нас таки неосуществимые либы.

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

Не буду я ниоткуда вылезать Не используем мы БД, по крайней мере в САПРе. А остальной документооборот электронный конечно, но к САПРу никак не привязан. Вся связь через парт_намбер в ВОМе.

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

С чего вдруг такой вывод???? Вы же не знаете возможностей DE HDL, о чем и писали чуть не в самом начале обсуждения. Причем советуя человеку на него не переходить и аргументируя это тем, что CIS в HDL не реализован.



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

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

Пардон, а Вы всю КД в DE HDL собрались рисовать? Вот с того и такой вывод.

Ну не передергивайте. Я советовал человеку не бросать оркад только потому, что не получается настроить CIS. Или Вы хотите сказать, что CIS в HDL есть?


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


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

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

А насчет CIS все просто. Что такое CIS? Это всего лишь Component Information System. Если в САПРе предусмотрен механизм хранения не только символа-футпринта компонента, но и доп. информации о нем любого рода, плюс функции манипулирования этой информацией, то можно смело говорить - да, САПР поддерживает CIS. И по большому счету не важно, в каком виде это реализовано, если позволяет удобно работать.

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

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