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


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

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

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

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

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

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



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

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

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

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


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


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

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

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

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

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

Никто и не спорит. Речь ведь не о том, кто чем будет заниматься, а о том, какая под этим информационная основа. Вот я, например, рисую схемы. Но мне очень полезно иногда знать, где на складе взять резистор, чтобы напаять на макет. И т.п.


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

Исключительно Ваше субъективное мнение.



Все понял. Успехов в эмуляции жизни

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

Еще меня интересуют способы учета состава изделий.

Вот тут сказано:

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

могу посоветовать ссылаться из таблицы компонентов/сборок на таблицу спецификаций ( отношение один к бесконечности) . В табл спецификаций два важных поля ID верхней сборки и ID подчиненной сборки (либо уже неделимый компонент типа ПКИ, деталь, дока и т.д.)
ID подчиненной сборки обратно ссылается на ID таблицы компонентов/сборок (бесконечность к одному). В таблице спецификаций обязательно также поле "количество" - по смыслу. Таким образом организуется ветвление сборок с неограниченной вложенностью. Обсчет структуры спецификации предусматривает рекурсивность.

Таблица спецификаций может быть не одна - по вкусу и удобству программирования запросов.

Остальное понятно и естественно, а про это вопрос.
Зачем количество? Т.е. что оно дает, кроме экономии памяти? Ведь его же тоже еще надо узнать (подсчитать). Я первоначально думал создавать структуру путем заргузки бома, в котором группировка отсутствует...

это количество однотипных позиций в одной строке конструкторской спецификации (не во всем изделии !) . скажем так - 5 винтов M3х10 - которые записываются одной строкой в спецификации

или 3 резистора МЛТ-1 2.2 кОм 10% . Про это количество речь.

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

Дык и я про них же.


Я под плоским видом понимаю такой вид, когда один экземпляр перечисляется в одной строке. Если САПР подсчитывает, то происходит группировка, верно? А против сгруппированных элементов ставится количество.

Судя по этим словам:

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


Ммм... Не понял. А почему ручками? Что мешает сделать ссылки на другие объекты в той же базе автоматом?

Затем, чтоб после втыкания в ветку дерева спецификаций происходило мгновенное отображение этой спецификации в соседнем окне клиента.
И столбец КОЛ для спецификации должен быть единый - для глаза приятно.


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

Понятно. Я так и собирался поступить, в общем.


Ну я не настолько зол. Я считаю, что работа конструктора состоит не в оформлении спецификации, и даже не в оформлении чертежа (!), а в разрабтке конструкции. Но это просто к слову.

А еще вопрос. Вы сказали, что у Вас и чертежи тоже электронные. А в чем рисуете? Компасом пользуетесь? Тут уже пару лет вяло пытаюсь заинтересовать конструкторов и заставить их сделать список деталей, нарисованных на чертеже, в виде текствого файла (бома). Они говорят, что это нереально (только для 3D можно экспортировать в ексель и далее). Это правда?

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

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

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