[vitan 2]

Разделение функций(баз, систем, обязанностей .......) - это реально хорошо.

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

 

Кроме упрощения жизни это еще и делает систему более простой и устойчивой. Собственно это главный аргумент - чем проще система, тем проще ее поддерживать и обслуживать и тем меньше вероятности ее сбоя.

Я уже давно закрываю уши, когда слышу что-то подобное. Простые системы - простая продукция.

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

А уж и еж - это намноооого более высокоразвитые существа. С ними надо уметь обращаться. :)

[Uree 1]

Я уже давно закрываю уши, когда слышу что-то подобное. Простые системы - простая продукция.

 

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

 

Система не тогда эффективна, проста в обслуживании и надежна, когда она простая, а тогда, когда она отражает жизнь. И чем полнее и точнее, тем лучше.

 

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

[Буратино 0]

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

 

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

Идея иметь интерфейс моих компонентов с внешним миром, при этом удовлетворяя все внутренние потребности программы по работе с библиотеками, мне симпатична, а время расставит все по своим местам и лишнее отвалится само собой.

[vitan 2]

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

 

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

Можно заявить отдельные ПКИ, можно составить заявку под план производства NN изделий , можно комбинированно.

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

[тау 23]

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

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

 

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

[vitan 2]

В таблице спецификаций обязательно также поле "количество" - по смыслу.

Остальное понятно и естественно, а про это вопрос.

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

[тау 23]

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

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

 

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

 

Эти количества импортируются из БОМА САПРА в конкретную сборочную единицу в "плоском" неразветвленном виде. САПР подсчитывает. А дерево с ветками сборок уже делается ручками в клиенте базы.

Подсчет однотипных компонентов во всем изделии делается с вершинной ветки дерева для конкретного изделия рекурсивной процедурой путем суммирования этих элементов в каждой входящей сборке с умножением на количество сборок в верхней ветке и так снизу вверх от упора до упора.

я не понял что там Вам "еще надо узнать (подсчитать)"?

Я первоначально думал создавать структуру путем заргузки бома, в котором группировка отсутствует...

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

Изменено 18 июля, 2011 пользователем тау

[vitan 2]

Про это количество речь.

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

 

Эти количества импортируются из БОМА САПРА в конкретную сборочную единицу в "плоском" неразветвленном виде. САПР подсчитывает.

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

 

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

Подсчет однотипных компонентов во всем изделии делается с вершинной ветки дерева для конкретного изделия рекурсивной процедурой путем суммирования этих элементов в каждой входящей сборке с умножением на количество сборок в верхней ветке и так снизу вверх от упора до упора.

у Вас таки из САПР выдается "обычный" бом, без группировки. А группировку Вы делаете уже в спецификации.

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

 

А дерево с ветками сборок уже делается ручками в клиенте базы.

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

[тау 23]

у Вас таки из САПР выдается "обычный" бом, без группировки. А группировку Вы делаете уже в спецификации.

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

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

И столбец КОЛ для спецификации должен быть единый - для глаза приятно.

 

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

Делайте на здоровье. Вообще сделайте одну кнопку - Синтез спецификации. Вообще думать не надо , нажал кнопку - вся спецификация сразу автоматом готова :) . Конструкторов поувольнять за ненадобностью.

А "ручками" - это как раз и есть наведение ссылок , потому что если для Сапра печатных плат импорт списка легко автоматизируется, то для всяких винтов, клеёв, этикеток, и прочей мутоты это есть некоторая проблема. Но вероятно Вы и её автоматизируете :).

[vitan 2]

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

 

Конструкторов поувольнять за ненадобностью.

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

 

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

[тау 23]

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

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

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

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

 

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

Изменено 19 июля, 2011 пользователем тау

[vitan 2]

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

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

Ну и вообще: существуют ли такие механические САПРы, в которых работа с базой ведется, например, по аналогии с тем же CIS?