Центральная БД предприятия Опции

[Nemod]

Хотим перейти на Orcad/Allegro.
Пока конечно мало о нем знаю (почитал по диагонали Kreig Mitzner и прочие доки).
Встал вопрос об организации центральной БД компонентов используемых в изделиях предприятия.
Как это лучше сделать для "Orcad Capture -> PCB Editor" Flow?
CIS я так понял это просто надстройка содержащая ссылки на файлы падстаков и OLB. И если это так то сложно его назвать базой данных, это просто представление данных которые валяются в виде файлов и редактирование происходит вообще не через него (может я чего-то не нашел).

Сейчас основная идея вынести файлы на сервер и там их редактировать, но возникает тогда проблема совместного доступа.
Т.е как разрешить конфликты совместного редактирования OLB файлов?
И есть ли возможность хранить данные как-то в другом виде например в БД в виде BLOB полей или таких же файлов но чтобы конфликты доступа разрешал сервер?

[vitan]

Просто представьте себе , что вам нужно заказать 450 резисторов отсортированных в алфавите..

Я не могу представить, пока не увижу от Вас примера. Со своей стороны могу привести пример, в котором это трудностей не составляет. Вот он:

Код

cr0603-fx-101e
cr0805-jx-473elf
etc

А Ваш пример какой?

vitan, да, берите обратно свои слова об Access.

Беру.
Интересно, а Вы уже имеете рабочую систему с аксессом? Шутка.

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

Эээ... Как это: счет в мусорку? А если там компоненты, которые можно купить только сейчас и больше нигде, а завтра будет дороже. Или еще чего-то подобное?
А как у Вас потом ведется учет денег? Ведь получается, что в КД написано одно, а в финансовых документах - другое? Вы говорите, что критичные суффиксы пишутся в КД, а закупщик проинформирован. Как? На словах?
Табличка - правильно, мы тоже что-то типа этого делаем, но она может не помочь, если компонент применяется впервые, согласитесь.

[Буратино]

Я не могу представить, пока не увижу от Вас примера. Со своей стороны могу привести пример, в котором это трудностей не составляет. Вот он:

Код

cr0603-fx-101e
cr0805-jx-473elf
etc

А Ваш пример какой?

Этот вопрос считаю закрытым. У меня будут компоненты отсортированы по номиналу. Во-первых это требование ГОСТа, во-вторых это логично, что не менее важно.

Интересно, а Вы уже имеете рабочую систему с аксессом? Шутка.

Да, конечно. Я работаю в связке Altium/Access. Для ввода данных в базу данных используется клиент написанный на VB

[vitan]

Этот вопрос считаю закрытым.

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

у нас половина счетов проходит через мусорку такова жисть.
если Кд будет следовать наименованиям тупых менеджерских фантазий в счетах - это дело надо пресекать. Мы пресекли. А вы еще нет ?

Я не смог. Расскажите, как!
Нет, серьезно! Если половину счетов - в мусорку, то как же работать? Вам действительно удается заставить менеджеров переписывать счета?

Эталоном для бухов считается то что записано в базе - остальное суррогат и неправда. в очевидных случаях бухгалтерия сама ориентируется, что чему соответствует по счетам, а в неочевидных - мы ей подскажем, для подстраховки даже бумажку напишем что считать чем (когда просят перевести туфту на нормальный язык).

Читаю и не верю своим глазам! Я хочу у Вас работать! У нас, чтобы заставить бухгалтерию что-то понять, надо быть, как минимум финансовым директором! А эталон - только счет.

[Буратино]

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

Так вы вы в базе ведете одно а в спецификацию выводите другое? Тогда это лишний труд плюс гора ошибок.
У меня в базе всего несколько полей ID, ParentID, Name, Library Ref, Footprint Ref и никаких дополнительных полей. Поля ID и ParentID и определяют иерархию.

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

Эскизы прикрепленных изображений

 

[vitan]

Так вы вы в базе ведете одно а в спецификацию выводите другое?

Этот вопрос закрыт, не так ли?

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

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

[Буратино]

Этот вопрос закрыт, не так ли?

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

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

Вы видите проблему, а я решение проблемы. Для меня важно смотреть на компоненты именно в таком разрезе и желательно при этом понимать что эти компоненты либо есть на складе либо их реально можно достать без траблов. На этом стоп, дальше совсем другая песня и совсем другие подходы. И если есть желание решать эти другие вопросы, в том числе и те о которых уже говорили выше, то нужно не смешивая одно с другим строить параллельные системы и связываться по ключу, который собственно может быть составным, ну это уже тонкости.
В том то и дело, что если правильно разделить таблицы, то можно будет казалось бы несовместимые вещи совместить. Мне например нужна "схемотехническая" база моделей, а бухгалтер должен работать с первичкой, но связаться эти два вида деятельности/работ могут и должны именно на основе компонента, его уникальности и свойств. Тогда, и только тогда, можно будет каждому заниматься своим делом, при этом работая в единой системе "Центральная БД предприятия"

[vitan]

Мне например нужна "схемотехническая" база моделей, а бухгалтер должен работать с первичкой, но связаться эти два вида деятельности/работ могут и должны именно на основе компонента, его уникальности и свойств.

Звучит правильно, но меня терзают смутные сомнения... Схему данных можете показать?

Читаю и валяюсь... И после этого кто-то кидает камни в сторону Design Entry, который не-CIS? Успехов в ваших базах Концепция, философия... а на самом деле получаются костыли, для подпорки процесса который без них не может обойтись. Нет, я понимаю, что в данных реалиях без этого обойтись не получается, но выглядит все это грустно...

Это Вы о ком? И о каком процессе? Как вы его себе представляете?