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


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

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



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

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

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

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

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

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

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

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

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

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

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

Сообщение отредактировал тау - Jul 18 2011, 20:10

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


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

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

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


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

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


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

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


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

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

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

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

Сообщение отредактировал тау - Jul 19 2011, 09:33

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