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

[Nemod]

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

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

[lazarev andrey]

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

[vitan]

или не так задали вопросы

Скорее это.
Вы сильно большой вопрос задали. Много писать не хочется. По частям спрашивайте лучше.

[lazarev andrey]

Скорее это.
Вы сильно большой вопрос задали. Много писать не хочется. По частям спрашивайте лучше.

как заставить жить (настроить) всю директорию с самой базой данных, библиотекой символов, футпринтов (и им сопуствующих), spice моделей на сервере?
делается ли так вообще (правильно ли это)?
возможно ли это? если да, то как?

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

что то опять получается много

мануалов толком нет или не там ищу

[vitan]

делается ли так вообще (правильно ли это)?

Делается. У нас я так и сделал. Только это вызывает необходимость координировать совместное использование общих ресурсов. У меня, например, это делается с помощью систем контроля версий и управления процессами, которые не привязаны к каким-либо САПР вообще.
Пользователям закрыт доступ к общим ресурсам иначе чем через контроль версий, а к некоторым ресурсам еще и процесс написан. Работает.

[Nemod]

Делается. У нас я так и сделал. Только это вызывает необходимость координировать совместное использование общих ресурсов. У меня, например, это делается с помощью систем контроля версий и управления процессами, которые не привязаны к каким-либо САПР вообще.
Пользователям закрыт доступ к общим ресурсам иначе чем через контроль версий, а к некоторым ресурсам еще и процесс написан. Работает.

Во. Можно поподробнее?
Я предполагал следующую схему:
1. Создать репозиторий на сервере SVN для библиотеки
2. Закоммитить туда каталог со всей фигней (футпринты, олбэшки и т д)
3. Каждый пользователь для обновления своей локальной БД делает update в настроенную для Capture/PCB Editor директорию (я думаю в пределах компа проблемм с переносом не будет).
4. Пользователь может локально внести изменения и закоммитить их затем на сервер.

Но возникают вопросы, как то - 2 пользователя подправили один olb файл, естественно первый его закоммитит, а у второго возникнет конфликт при попытке обновится (иначе не закомитится). Естественно как то разрешать конфликты в SVN удобно только для исходников, а что делать здесь??.
Нет ли проблем со служебными каталогами .svn (если кто-то использует subversion)?
Может лучше GIT?

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

[vitan]

3. Каждый пользователь для обновления своей локальной БД делает update в настроенную для Capture/PCB Editor директорию (я думаю в пределах компа проблемм с переносом не будет).

У меня есть отдельный каталог на сервере, в котором отражается текущее состояние репозитория. Каталог доступен только по чтению. Юзерам рекомендовано пользоваться им как основной центральной библиотекой. Но не запрещается пользоваться своими локальными.

Но возникают вопросы, как то - 2 пользователя подправили один olb файл, естественно первый его закоммитит, а у второго возникнет конфликт при попытке обновится (иначе не закомитится). Естественно как то разрешать конфликты в SVN удобно только для исходников, а что делать здесь??.

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

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

Да ну! У меня именно ментор и все нормально. Интересно, в чем были трудности?.
А в альтиуме, кстати, вроде встроенная поддержка SVN.

[Nemod]

У меня есть отдельный каталог на сервере, в котором отражается текущее состояние репозитория. Каталог доступен только по чтению. Юзерам рекомендовано пользоваться им как основной центральной библиотекой. Но не запрещается пользоваться своими локальными.


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


Да ну! У меня именно ментор и все нормально. Интересно, в чем были трудности?.
А в альтиуме, кстати, вроде встроенная поддержка SVN.

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

Была проблемма когда я запихал БД в свн. Central library воспринимал подкаталоги svn как часть этой библиотеки и выдавал всякую билеберду. DxDesigner/Expedition flow. EE 2005 вроде.

Про альтиум не знаю. Может быть. И что svn там не только для исходных текстов vhdl/c++ применяется?

В любом случае svn для этих баз данных это на крайний случай. Правильнее бы было работать через odbc.

Кстати если порытся на сайте то можно и найти эти проблеммы совместимости svn и expedition http://electronix.ru/forum/index.php?showt...p;hl=Subversion

[vitan]

В любом случае svn для этих баз данных это на крайний случай. Правильнее бы было работать через odbc.

А никто и не говорил, что надо svn применять для баз данных. Это надо применять для контроля версий угошников и футпринтов. А с БД работать через ODBC или еще какой интерфейс, это да.

[Nemod]

А никто и не говорил, что надо svn применять для баз данных. Это надо применять для контроля версий угошников и футпринтов. А с БД работать через ODBC или еще какой интерфейс, это да.

Базой данных я назвал собственно набор угошников и футпринтов. Которые в оркаде хранятся в виде файлов в каталогах.
Это же и есть ваша база данных. И вот с ней надо работать через ODBC, а не через проводник. В нашем случае Windows explorer (если точнее Windows API для файлов) тоже является средством доступа к БД, только он разрешает проблеммы совместного доступа на уровне файлов (файл == одна запись в БД). Но проблемма в том что у оркада один файл соответвует нескольким записям.

И ещё через с оркадом можно было бы нормально работать с БД на уровне файлов, если бы перед сохранением компонента он заново загружал файл с источника (на тот случай если его уже кто-то добавил новый компонент или отредатировал ваш, пока вы правили компонент), помечал его признаком только чтения (на время сохранения), вносил изменения (разрешал конфликты если они есть) и сохранял.
Сейчас он сохраняет olb файл видимо прямо из своего ОЗУ не проверяя внесли ли в него изменения пока он был открыт у вас.

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

Кто нибудь знает Capture будет когда-нибудь под линух? или надо под HDL переходить?

Сообщение отредактировал Nemod - Jun 21 2011, 18:09

[vitan]

Базой данных я назвал собственно набор угошников и футпринтов.

Что-то у Вас намешано все в кучу...
1. Базой данных большинство называет СУБД (обычно реляционную) и сами данные под управлением ее. И правильно делают. Предлагаю не отклоняться от общепринятой терминологии. Понятно, что в общем виде можно рассматривать файлы как БД, и даже существуют драйверы ODBC для такой "БД", но это фигня а не БД, не так ли? Наборы угошников и футпринтов традиционно называются библиотеками, тоже думаю отторжения не вызывает.
2. Не надо переходить на HDL только потому, что не получается коллективная работа в Capture. Надо настроить коллективную работу. Что Вам мешает, например, организовать хранение библиотек (УГО и футпринтов) под управлением контроля версий, а не в расшаренной папочке как сейчас? Это первый шаг, часто основной. Если его сделаете, дальше само пойдет.
3. Capture отлично справляется с коллективными компонентами, т.к. у него есть CIS. А в HDL, кстати, нет. Чтобы настроить CIS, нужна нормальная БД. Конечная цель в плане организации работы рисовальщика схемы - дать ему набор групп компонентов (это тоже традиционно называют библиотеками, но это уже другие библиотеки), к которым будет доступ из Capture, причем информация о параметрах (номиналы, например, корпуса) будет браться из БД.
4. Чтобы этой цели достичь, надо, чтобы БД была адекватной, а у юзеров была возможность ею пользоваться, не особо отвлекаясь от основной задачи. Это непросто, особенно, если у Вас не запланирован отдельный человек на должности библиотекаря/администратора БД. Здесь возможны варианты с монопольным доступом администратора к компонентам, системы контроля процессов или вообще обычные транзакции СУБД, дело времени и вкуса.
Вот тут альтиумовцы тоже этим озаботились, я там несколько идей по этому поводу тоже высказывал, может, Вам подойдет (п.4 я имею ввиду, остальное и обсуждать нечего, стандартный путь).