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

А можно ли сделать реляционную базу для CIS?
Например хучу я вынести корпуса в отдельную таблицу (footprint_id, footprint). А в основную таблицу подставлять footprint_id.
Как при этом для компонента сделать несколько корпусов?
Как при этом будет работать добавление новой записи через CIS?
Возможно ли так построить базу? Может использовать для этого не Access?

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

В базах я совсем не силен.

И еще, может кто встечал Merge Tool для Access? А то я ничего внятного не нашел.

John Silver
Все то, что Вы говорите, делать можно. Только это надо делать правильно. Про организацию очень советую прочитать ветку про БД из секции альтиума.
Добавление компонентов выглядит так же, как и без базы, только окошко чуть другое.
И не надо искать merge для access. Он где-то был, но не надо.

Почитаю, спасибо. А может, vitan, у Вас найдется примерчик такой базы?


Эт почему не надо? Где он был?
Очень нужный инструмент, и очень хорошо ложится на данную тему. Есть несколько разработчиков, каждый использует свою локальную базу, и через некоторое время мержатся.

Вот там как раз примерчик и есть.


Потому что делать корпоративную базу на аксессе - все равно, что разводить платы в пикаде 4.5. Ну не тот это инструмент.
Примерчик, кстати, приведен только в виде структуры, ну и картинки есть из клиента (аксесса нет).

Почему бы и нет?
Скажите пожалуйста чего не хватит Вам для решения данного вопроса в Microsoft Access? Ну что именно помешает? А как нужно делать? Спасибо!

Ну, у нас не корпоративная база, а совсем даже отдельная.
И ваще, Access обладает рядом преимуществ, например не надо поднимать сервер БД, средства редактирования уже, как правило, установлены на компе. И какие вы бы предложили альтернативы для отдельной, не корпоративной БД?
Ну и к нашим баранам мерж туламГде же можно взять сей чудесный инструмент? Если уж не бесплатный, то хотя бы излечённый.

PS Эта тема?
Т.е. создаем запросы (это как View в Oracle?). Думал о таком варианте, но по моему, тогда не будет работать добавление нового компонента средствами CIS.

О май гад! Оставим...


Postgre MySQL, SQLServer и т.п.


Я поищу, но не гарантирую, т.к. с аксессом завязал много лет назад. Возможно, это будет тулза с GUI, возможно - в виде текстовых SQL-запросов, просто не помню.
А можно узнать, зачем она Вам нужна? Будете мержить несколько файликов из песочниц на сервер? УЖОС!


Не совсем, там выделили отдельно.


Начал было писать ответ, но понял, что лучше не надо. Опять холивары разводить не хочется. Каждый должен через это пройти сам, видимо.
Скажу одно: это просто программа не для этих целей. Не для серьезной работы. Обратите внимание, кстати, у того же производителя есть и другой продукт (посолиднее).


Тут не надо думать, без запросов в БД делать нечего.

Для правильной организации всего процесса управления библиотеками на предприятии нужно прикинуть для чего все это затевается! Давайте ответим на этот вопрос все вместе, и лично я бы был рад:
1. Возможности вести единую базу УГО ,футпринтов. Для меня принципиально важно, чтоб компоненты складывались из моделей, которые лежат в одном месте а не разбросаны по сотням файлам. В данный момент у меня один файл содержит все УГО, другой все футпринты которые я использую в работе. Это позволяет решить многие вопросы.
2. Иметь возможность получать в автоматическом режиме перечни и спецификации к платам. Как показывает практика, этот вопрос решается только при хранении компонентов в иерархически сортированном виде. Речь идет о модели в которой например резисторы одной группы лежат в базе строго по возрастанию номинала, а не (например) в порядке их добавления в базу.
3. Иметь возможность выбирать компонент, который реально присутствует на складе предприятия. Ну например стаскиваете вы в своей САПР на схему резистор 1к, а потом обращаете внимание что 1к в данный момент осталось на складе предприятия 1500 штук и вы решаете поставить 1,2к которых завалялось 148000 штук
4. Распараллелить работу с базой между несколькими пользователями.

Что важно для вас? Опишите ваши потребности!




В Microsoft Access входит лайт MS SQLServer, и уже одно только это повод серьезно относиться к программе.
По простоте и качеству методов доступа к данным ацес не имеет себе равных, а эта конкретная задача, по большому счету - альтернатив. Ну уж точно для большинства присутствующих. Кроме самой структуры хранилища, вариантов представления, нужно еще решить вопросы с вводом информации в систему, контролем и возможностью редактировать ранее введенное. Или вы планировали помимо чистого MS SQLServer задействовать C# для построения форм ввода и администрирования?

---
Одно дело когда вы попробовали софт и составили о нем некоторое представление, другое когда навязываете свое мнение по данному вопросу другим.

Хорошая постановка задачи. В моем случае мне просто надоел вечный бардак, ну и наблюдались некоторые сложности с применением/заимствованием компонентов внутри группы людей.


Согласен. Я это называю "центральной библиотекой". Имхо хороший термин (взят у ментора). Правда при этом я считаю неважным, как физически хранятся УГО, футпринты, модели и т.п. (в одном файле или нет), главное, чтобы управление ими было централизовано тем или иным способом.


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


Связь со складом тоже очень нужна. Только она сопряжена с некоторыми трудностями. У нас, например есть такая программа, 1С называется. Там все как и везде у нас - через одно место.


Ну это уж само собой.


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

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

Еще мне нужна была независимость от применяемых САПР (их несколько, как для схематики, так и для PCB).



Не обязательно C#. В моем случае нет никаких "форм ввода". Есть нормальная программа-клиент, там есть весь функционал. В будущем, возможно, будет веб-клиент (то же самое, только на сервере http).


Надеюсь, что имею. Перед тем, как строить что-то свое, долго пытался пристроить покупные решения. Наиболее правильной для нашей действительности считаю связку Mentor DMS+Intermech Search. Только мучений по настройке там никак не меньше, чем делать все свое. А мнение я не навязываю, наоборот, предлагаю все пройти самому. Обычно энтузиазм у спорщиков пропадает после первого года пути и они больше не отвечают на посты...

у нас это все реализовано и работает давно . Как бонус ,кроме перечней и спецификаций "к платам" в базе хранится вся остальная КД , вместе с чертежами сборок. У нас нет в этой связи подлинника КД на бумаге - он в базе

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

Да, клиент требует усилий.

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

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


А можно здесь поподробнее, в плане обмена опытом, так сказать? У Вас закупки начинаются из этой базы, а не из 1С?


Я правильно понял, что заказ компонента инициируется техническим сотрудником (инжереном-разработчиком) в его базе, а бухгалтерам попадают некие заявки, которые они вручную обрабатывают и дальнейший учет ведут в 1С?


В смысле, указанная база и база 1С синхронизированы по полю "партнамбер"?


Да Вы как-то не особо и спорили там.


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

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




Для оформления спецификации необходимо, помимо прочего, сортировать компоненты по номиналу внутри группы и соответственно, в обсуждаемой БД, необходимо вести признак по которому ваша система отсортирует компоненты. Ну например как вы планируете правильно расположить конденсаторы в группе спецтфикации если их номиналы могут записываться как 0,1u и также могут записываться как 2200р ? Или вы считаете что спецификацией и перечнем должны заниматься другие?





1С одна из лучших программ современности, а трудности сопряжения с ней сильно преувеличены.

Мысль интересная, только надо уточнить.
1. Вы говорите про оркад?
2. Для чего нужно групповое редактирование? Понятно, что перед отправкой на разные заводы может понадобиться изменить толщину линий. Но не лучше ли это отнести на этап подготовки к производству? Обычно там, кстати, много чего другого корректируют. Это еще зачем-то может понадобиться?

В защиту моего способа есть аргумент, что обычно много однотипной работы поручают программам (скриптам). Если надо - напишем.


Сортировть надо не по номиналу, а по алфавиту. Где сказано, что по номиналу?

Mentor DMS+Intermech возможно и правильно (я лично понятия не имею что за софт) но мне так и не удалось выяснить у вас чем-же именно акцес не угодил? Какие трудности, траблы и т.п.


Если так то скажите пожалуйста в каком виде формируется спецификация, присутствует ли сортировка внутри группы? Если так ,то как вы меняете номера компонентов если нужно добавить номинал например конденсатора? Вот нет у вас в базе номинала 2,2p например, вы добавляете его в базу но под каким номером, ведь этот самый номер должен отражать позицию конденсатора в иерархии номиналов! Или ві формируете в условном виде спецификацию, которую потом день нужно таскать конструктору, чтоб привести ее в надлежащий вид. Можно пример того что вігружает ваша система в виде спецификации? Спасибо!




Правда? Ну и как ваша система отсортирует по алфавиту 0.1u, 10n, 2200p например? Это же касается и резисторов и многого другого. Нет, должен вестись признак позиции в группе, иначе это все не наш путь.