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

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

как я понимаю вы только решаете на какую программу перейти... с одной из целей которых будет - построение (подвязка) пути к базе данных эл-ых элементов фирмы - в данном случае лучшее решение этой задачи представлено в системе программ Altium - так что у вас еще есть время подумать какую систему покупать... советую - Altium 10... удачи

CIS-автоматически синхронизирует и выверяет данные о компонентах во внешних базах данных и базе данных проекта. CIS опции реализуют интерфейс с любой базой данных, которая удовлетворяет стандарту Microsoft’s ODBC. Возможен непосредственный доступ к данным, хранящимся в системах MRP, ERP и PLM при построении моделей компонентов. Гибкость системы позволяет нескольким пользователям осуществлять одновременный доступ к информации без взаимовлияния. Благодаря быстрому доступу, удобной системе поиска и возможности вставки компонентов в проект непосредственно из внешней базы, CIS значительно сокращает время разработки печатной платы.

Кроме того, существуют программные продукты Cadence Allegro Design Workbench и Allegro PCB Librarian

чтобы не плодить тут тем.

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

или надо в начале каждого проекта просто скачивать все на локальный компьютер, на котором установлен САПР?

просто, у меня не получается настроить, может не с того конца начал или вообще не так все понял.

Все какие-то общие фразы, типа наш продукт лучше и поддерживает те и те интерфейсы.

Ну вот что он выверяет? номиналы, названия. И нафига на начальном этапе наполнения БД это нужно.
Вопрос не в том что ODBC, а что она там по этому интерфейсу ODBC сохраняет. Падстаки, футпринты она по нему сохраняет, символы компонентов? Вот чего я не нашел.


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


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

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

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

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

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

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

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

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

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

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

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

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


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


Да ну! У меня именно ментор и все нормально. Интересно, в чем были трудности?.
А в альтиуме, кстати, вроде встроенная поддержка 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

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

Да, суръёзная проблема. Тоже много думал над ней.
vitan правильно все говорит, доступ к библиотечным файлам реализуется через контроль версий.
Если репозиторий лежит в локальной сети, то Аллегру настроить непосредственно на репозиторий,
если в интернетах, то использовать локальный репозиторий.
Править же сами файлы необходимо средствами контроля версий.

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

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

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

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

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

Что-то у Вас намешано все в кучу...
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 например? Это же касается и резисторов и многого другого. Нет, должен вестись признак позиции в группе, иначе это все не наш путь.

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


Вы ГОСТ покажите сначала.


Во-первых, строка "10n" уже ошибочна, ибо номинал должен записываться как "10 нФ". Во-вторых, можно спросить, а что Вы этим хотите добиться?

Я просто спросил у конструкторов как делать спецификацию, люди как бэ за это деньги получают. Но лично кажется достаточно логично и правильно сортировать по номиналу.
Вот нашел какой-то первый попавшийся (см. картинку):
ГОСТ 2.108-68
Единая система конструкторской документации
Спецификация


Быстро Вы однако сдались ,дело в том что весь функционал MS SQL Server можно использовать в Microsoft Access. И триггеры и хранимые процедуры и все остальное. Повторяю в состав поставки Access входит SQL Server.



Вы понимаете меня ,на чем именно я поставил акцент понятно? А добиться я хочу правильной и эффективной работы с ПО.

Закупки начинает заинтересованное лицо из базы. Можно заявить отдельные ПКИ, можно составить заявку под план производства NN изделий , можно комбинированно. Закупщик по заявке запрашивает поставщиков , получает счета, вбивает в базу дату и номера счетов, сроки оплаты ( если узнает у бухов) , сроки поставок, и прочее прочее , пока товар не придет на склад.

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

да.

Пожалуй откажусь, вот такой вот я фрукт.

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


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

Читайте внимательно: п.8 описывает правила записи стандартных изделий, а электронные компоненты надо записывать в прочие изделия. Кроме того, выделение красным начинается после слов "в пределах каждого обозначения стандарта". Выше написано, что в пределах группы - по алфавиту.


Готов взять свои слова обратно, лишь бы не спорить об аксессе. Черт меня дернул...


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


А вот что Вы делаете, когда счет Вам пришел, а там написано не то, что Вы заказывали (до буквы не совпадает). Думаю, Вы понимаете, о чем я.


Знаю-знаю! Это от лени, чтобы не забивать эти параметры из даташитов в базу при добавлении компонентов. Угадал?

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

Если из 1С нельзя "взять" текущее состояние склада по той или иной позиции, то это уже не бухгалтерия.

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

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

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

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


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


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

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


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

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

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

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


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


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

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

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

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


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

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



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

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

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


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

Насчет отсутствия CIS или аналога в Design Entry - о Вас. Но понимаю, Вы просто не знаете как там либы устроены. На базу не очень возможно похоже, но судя по вашим общим дебатам - куда удобнее. Хотя как всегда - вопрос вкуса и потребностей.
А процес понятно какой - разработки и производства. Собственно от попыток их подружить у вас и проблемы. Есть и еще слагаемые у проблемы, но на них вы точно повлиять не можете.
А процесс я не представляю, я его немножко знаю, но в другом свете, вам эти знания вряд ли пригодятся. Собственно потому и в дебаты не вступал.

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

А Вы уверены, что база данных это единственный выход в данном случае?

Ок. Больше не вмешиваюсь.

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

Сейчас я работаю с Альтиумом и самого начала решил перейти к базам и вот почему:
1. Устраняются разночтения и неточности в вариантах наименований, так как я в схему стаскиваю готовый компонент с параметрами и номиналом. Экономится труд так как номинал и упомянутые параметры заполняются единожды, а используются многими и многократно.
2. Есть возможность связать с конкретным компонентом и номиналом - базы и склад, при этом не увеличивается размер библиотек ибо физические УГО и футпринты не дублируются, и представлены как строка в базе данных, при этом появляются возможности редактирования параметров и передачи изменений на схемы и платы.
3. Автоматизация создания конструкторской документации, в том числе перечней и спецификаций.

Без использования базы данных все это если и возможно, то через неправильные места.

"для связи с другими массивами данных" - с какими именно?

1, 2, 3 - это все понятно. Непонятно только почему это обязана быть БД. Design Entry HDL осуществляет доступ к этой инфе непосредственно из текстовых файлов например, в этих же файлах, как атрибут, вписан линк в систему электронного документооборота, указывающий на файл, с перечнем источников данного компонента:

PART_NUMBER | VALUE | TOLERANCE | PART_DESCRIPTION | JEDEC_TYPE | STATUS | INSERTION | VOLTAGE | RATED_CURRENT | RATED_POWER | SCD_LINK
==============}
'RTK-0402F-000R-B' | '0R' | '1%' | 'RES THKFLM 1/AMP SMD 200TC 50V JUMPER 00R SMD0402' | 'RESC_0402' | 'ACTIVE' | 'SMD' | '50V' | '1A' | '0.0625W' | 'http://twdocs.adb.pl/doc/91016'
'RTK-0402F-01R0-B' | '1R' | '1%' | 'RES THKFLM 1/16W SMD 200TC 50V E96 1% 1R0 SMD0402' | 'RESC_0402' | 'ACTIVE' | 'SMD' | '50V' | '1A' | '0.0625W' | 'http://twdocs.adb.pl/doc/91016'
'RTK-0402F-01R2-B' | '1R2' | '1%' | 'RES THKFLM 1/16W SMD 200TC 50V E96 1% 1R2 SMD0402' | 'RESC_0402' | 'ACTIVE' | 'SMD' | '50V' | '1A' | '0.0625W' | 'http://twdocs.adb.pl/doc/91016'
'RTK-0402F-01R3-B' | '1R3' | '1%' | 'RES THKFLM 1/16W SMD 200TC 50V E96 1% 1R3 SMD0402' | 'RESC_0402' | 'ACTIVE' | 'SMD' | '50V' | '1A' | '0.0625W' | 'http://twdocs.adb.pl/doc/91016'
'RTK-0402F-01R5-B' | '1R5' | '1%' | 'RES THKFLM 1/16W SMD 200TC 50V E96 1% 1R5 SMD0402' | 'RESC_0402' | 'ACTIVE' | 'SMD' | '50V' | '1A' | '0.0625W' | 'http://twdocs.adb.pl/doc/91016'
'RTK-0402F-01R6-B' | '1R6' | '1%' | 'RES THKFLM 1/16W SMD 200TC 50V E96 1% 1R6 SMD0402' | 'RESC_0402' | 'ACTIVE' | 'SMD' | '50V' | '1A' | '0.0625W' | 'http://twdocs.adb.pl/doc/91016'
'RTK-0402F-01R8-B' | '1R8' | '1%' | 'RES THKFLM 1/16W SMD 200TC 50V E96 1% 1R8 SMD0402' | 'RESC_0402' | 'ACTIVE' | 'SMD' | '50V' | '1A' | '0.0625W' | 'http://twdocs.adb.pl/doc/91016'
'RTK-0402F-02R0-B' | '2R0' | '1%' | 'RES THKFLM 1/16W SMD 200TC 50V E96 1% 2R0 SMD0402' | 'RESC_0402' | 'ACTIVE' | 'SMD' | '50V' | '1A' | '0.0625W' | 'http://twdocs.adb.pl/doc/91016'
'RTK-0402F-02R2-B' | '2R2' | '1%' | 'RES THKFLM 1/16W SMD 200TC 50V E96 1% 2R2 SMD0402' | 'RESC_0402' | 'ACTIVE' | 'SMD' | '50V' | '1A' | '0.0625W' | 'http://twdocs.adb.pl/doc/91016'
'RTK-0402F-02R4-B' | '2R4' | '1%' | 'RES THKFLM 1/16W SMD 200TC 50V E96 1% 2R4 SMD0402' | 'RESC_0402' | 'ACTIVE' | 'SMD' | '50V' | '1A' | '0.0625W' | 'http://twdocs.adb.pl/doc/91016'
'RTK-0402F-02R7-B' | '2R7' | '1%' | 'RES THKFLM 1/16W SMD 200TC 50V E96 1% 2R7 SMD0402' | 'RESC_0402' | 'ACTIVE' | 'SMD' | '50V' | '1A' | '0.0625W' | 'http://twdocs.adb.pl/doc/91016'
'RTK-0402F-03R0-B' | '3R0' | '1%' | 'RES THKFLM 1/16W SMD 200TC 50V E96 1% 3R0 SMD0402' | 'RESC_0402' | 'ACTIVE' | 'SMD' | '50V' | '1A' | '0.0625W' | 'http://twdocs.adb.pl/doc/91016'
'RTK-0402F-03R3-B' | '3R3' | '1%' | 'RES THKFLM 1/16W SMD 200TC 50V E96 1% 3R3 SMD0402' | 'RESC_0402' | 'ACTIVE' | 'SMD' | '50V' | '1A' | '0.0625W' | 'http://twdocs.adb.pl/doc/91016'
'RTK-0402F-03R6-B' | '3R6' | '1%' | 'RES THKFLM 1/16W SMD 200TC 50V E96 1% 3R6 SMD0402' | 'RESC_0402' | 'ACTIVE' | 'SMD' | '50V' | '1A' | '0.0625W' | 'http://twdocs.adb.pl/doc/91016'
'RTK-0402F-03R9-B' | '3R9' | '1%' | 'RES THKFLM 1/16W SMD 200TC 50V E96 1% 3R9 SMD0402' | 'RESC_0402' | 'ACTIVE' | 'SMD' | '50V' | '1A' | '0.0625W' | 'http://twdocs.adb.pl/doc/91016'
.....

и таких записей 5408 только для резисторов. И никаких иерархий, структур и других усложнений инфы. Поиск как и маска выбора доступен по любому из параметров:

Нажмите для просмотра прикрепленного файла