[Uladzimir 72]

Хм... Разве для этого нужно так много времени?

Если есть, я всегда отвечаю

Вам не кажется, что слова "библиотека на основе БД для Altium Designer" и "Библиотекой компонентов называть совокупность компонентов, выводимых с помощью запроса (или напрямую из таблицы, что считаю неправильным) в САПР" обозначают одно и то же?

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

Второе весьма расплывчато. Одно слово "выводимых"-- куда выводимых на печать или для каких целей, и что под этим подразумевается.

Про первое определение, я могу расписать Вам подробнее.

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

Я отвечаю только на те вопросы, где компетентен и знаю решение или направление решения

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

С этим сложнее. Я легко принимаю чужие адекватные и подходящие мне решения. И только.

При этом Вы в в свою очередь не пытаетесь как-то переубедить.

И не считаю нужным. указываю как можно.и нужно. А другой или принимает решение, или идет другим путем, или наступает на грабли

Это мне не интересно.

Это точно. Пока в длинной дисскусии мы ни на йоту на приблизились в моей цели "библиотека на основе БД для Altium Designer"

Зато подняли ворох отвлекающих вопросов о просто базе данных

 

[vitan 2]

Второе весьма расплывчато. Одно слово "выводимых"-- куда выводимых на печать или для каких целей, и что под этим подразумевается.

В посте №55 написано, куда.

В САПР, эксель и т.п.

Для целей дальнейшей обработки. В САПР обработка подразумевает поиск подходящего компонента и установку на схему, в экселе она (обработка) состоит во всевзоможных преобразованиях, которые могут понадобиться для закупок, монтажа, хранения, ну и т.п. (если все это кому-то надо).

 

Про первое определение, я могу расписать Вам подробнее.

Спасибо. Было бы неплохо.

 

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

 

Хочу обратить внимание на одну деталь: несколько полей для вариантов Footrint.

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

То же относится к УГО. Если у компонента будет только одно УГО, как было написано выше, то это очень плохо.

 

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

 

Ну и по поводу внешней базы (склада) небольшой комментарий, раз уж прикрепили: поле "наименование" нужно брать из основной таблицы, чтобы не было дублирования. Цены учитывать просто так не получится. Для нормального учета цен нужно как минимум: поставщик, номер счет, дата, количество штук в партии. Эти вещи требуют серьезного усложнения структуры БД, которое тут никто не хочет обсуждать. Эти слова - для тех, кто может случайно взглянет, и захочет скопировать себе. Будьте осторожны, так нормального учета не получится. А еще не хватает места хранения...

[jkrieger 0]

Хочу обратить внимание на одну деталь: несколько полей для вариантов Footrint.

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

С замечанием согласен полностью. Однако пока мои навыки в MS Access не позволяют сделать как вы советуете =)

 

То же относится к УГО. Если у компонента будет только одно УГО, как было написано выше, то это очень плохо.

Тут нам играет на руку одна особенность Альтиума. В нем для каждого УГО можно создавать несколько начертаний (они хранятся под одним именем и являются единым символом). И поэтому вполне хватит одного поля.

 

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

Данное поле введено для тех, кто хочет при помощи запросов отделить разные типы компонентов в отдельные м.. категории. Мне например, нравится когда есть библиотеки Capacitors - SMD и Capacitors - Axial. Или транзисторы по типу проводимости надо будет разбить.

 

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

...

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

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

Обычно на предприятиях свои самописные базы, со своей спецификой. так что учитывать их в структуре ACL считаю бессмысленным. И внешнюю базу я сделал для того чтобы показать возможность связи с базой предприятия. А что там будет то уже дело каждого.

 

Кстати, к Ментору можно подключить библиотеку в виде БД? Если да, то может действительно стоит попробовать не останавливаться на Альтиуме?

[vitan 2]

С замечанием согласен полностью. Однако пока мои навыки в MS Access не позволяют сделать как вы советуете =)

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

 

Тут нам играет на руку одна особенность Альтиума. В нем для каждого УГО можно создавать несколько начертаний (они хранятся под одним именем и являются единым символом). И поэтому вполне хватит одного поля.

Интересная особенность. Такое вижу впервые. Тем не менее, для универсальности настоятельно рекомендую Вам проработать УГО и футпринты в том виде, как я описал выше. Тем более, вижу, Вы не зациклены на одном альтиуме.

 

Данное поле введено для тех, кто хочет при помощи запросов отделить разные типы компонентов в отдельные м.. категории. Мне например, нравится когда есть библиотеки Capacitors - SMD и Capacitors - Axial.

Вижу, у Вас есть стремление группировать компоненты по разным признакам... Это правильно! Только еще раз напоминаю, что признаков может быть много. Систему группировки компонентов (иерархию каталогов) я приводил выше, там даже скрин приложил.

Рано или поздно у Вас появится потребность группировать, скажем так:

Или транзисторы по типу проводимости надо будет разбить.

Вы же не будете для этого использовать Mounting Type, я надеюсь?

 

 

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

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

 

Кстати, к Ментору можно подключить библиотеку в виде БД? Если да, то может действительно стоит попробовать не останавливаться на Альтиуме?

Естественно, можно. Я именно так и работаю. И всех заставил.

Конечно, не надо останавливаться! Если хотите, можно перенести обсуждение в общий форум по библиотекам.

[jkrieger 0]

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

Аргументируйте, пожалуйста. И предложите альтернативы. Я сам не люблю проприетарное ПО, но вот как назло оно очень удобно =)

 

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

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

Ну таких примеров думаю можно привести море.

 

Вобщем как мне кажется, САПРонезависимая база это конечно круто, и мне лично интересно, но это все таки это отдаленная перспектива.

[vitan 2]

Аргументируйте, пожалуйста. И предложите альтернативы. Я сам не люблю проприетарное ПО, но вот как назло оно очень удобно =)

Нет, я не агитирую за бесплатные СУБД. Хотя, к примеру, MуSQL уже почти де-факто стандарт. Я против аксесса. Вы начали проект коллективной БД, да еще и с доступом через интернет. Как Вы думаете, сколько она продержится до первого падения? А будут ли довольны пользователи? Рассматривайте аксесс, как просто прогу из состава офиса. Тогда все станет на свои места, будете юзать его для мелких поделок в этом самом офисе, ну или дома, не далее.

 

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

Мне все равно, где находится топик, но так, возможно, правильнее. А вот разные базы - это не придется. Мы так и не договорились о терминах. Я специально предложил обсудить структуру и требования к БД в отрыве от САПР, ибо мне это кажется наиболее правильным. Более того, могу сказать, что в данный момент моя база успешно работает одновременно с тремя САПР (один схемотехнически и два по платам). Одновременно - значит, ничего не меняется в структуре, а проекты делаются параллельно в разных САПР. И это количество я хочу увеличить, в т.ч. и за счет альтиума.

 

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

Ну таких примеров думаю можно привести море.

Согласен. Если бы таких примеров не было, то и все САПРы были бы одинаковыми.

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

 

Вобщем как мне кажется, САПРонезависимая база это конечно круто, и мне лично интересно, но это все таки это отдаленная перспектива.

Я Вас не уговариваю сделать сразу поддержку всех вариантов. Тем более, что лично я видел пока только три схемотехнических редактора с поддержкой БД: DxD, OrCAD, и Altium. Я уговариваю решать вопрос "модульно", заложив в основу универсальный фундамент, который и пытаюсь обсудить.

[Uladzimir 72]

В посте №55 написано, куда.

В САПР, эксель и т.п.

Для целей дальнейшей обработки.

То есть вы под библиотекой рассматриваете общий случай, где вывод на САПР, в частности altium это один из доступных вариантов

Нет, я не агитирую за бесплатные СУБД. Хотя, к примеру, MуSQL уже почти де-факто стандарт. Я против аксесса.

Гм. Я не любитель аксесса. Это altium позволяет вводить из него элементы как будто они из родной библиотеки. Причем замечу, не использует даже простейших возможностей аксесса.

Вопрос встречный. сможет ли MуSQL подготовит данные так, чтобы воспринимал это Altium, или потребуется промежуточная перегонка в ACCESS./ Если да. То все прелести теряются.

Мы так и не договорились о терминах. Я специально предложил обсудить структуру и требования к БД в отрыве от САПР, ибо мне это кажется наиболее правильным.

В смысле БД правильный. Вопрос только в одном. Будет ли эта база работать напрямую из оболочки Altium.

Если нет. Она станет не интересна для этой ветки форума.

Цитата(Jack Krieger @ Oct 2 2010, 16:24) Тут нам играет на руку одна особенность Альтиума. В нем для каждого УГО можно создавать несколько начертаний (они хранятся под одним именем и являются единым символом). И поэтому вполне хватит одного поля.

Интересная особенность. Такое вижу впервые.

Отчего же . в PCAD такое тоже есть. Там и FootPrint может содержать не одно о несколько посадочных.

Но в я тоже за одно.

Но расскажу еще об подводном камне.

в Altiume позволительно прямо в схеме или PCB модифицировать УГО или Footprint/

А при синхронизации из базы-- возьмется то, что там стоит. Бац и ошибка в проектировании.

Проходили :(

Рано или поздно у Вас появится потребность группировать, скажем так:

Проходили. Были не только по проводимости, а по диапазонам мощностей, напряжений.

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

 

 

[vitan 2]

То есть вы под библиотекой рассматриваете общий случай, где вывод на САПР, в частности altium это один из доступных вариантов

Так точно. Общий случай - это то, о чем я стараюсь думать в первую очередь.

 

Гм. Я не любитель аксесса. Это altium позволяет вводить из него элементы как будто они из родной библиотеки. Причем замечу, не использует даже простейших возможностей аксесса.

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

Я посмотрел файлики .dblib и понял, что альтиум работает по-аналогии с остальными. Например, строки

UserWhere=1
UserWhereText=[Manufacturer] = '{Manufacturer}' AND [Manufacturer Number] = '{Manufacturer Number}'

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

А строки

[DatabaseLinks]
ConnectionString=Provider=Microsoft.Jet.OLEDB.4.0;Data Source=D:\resources\libraries\branch\ACL\Реплика ACL.mdb;Persist Security Info=False

наводят на мысль о том, что альтиум работает не только с аксессом, но еще и через ODBC с любой БД (как все нормальные программы).

 

Вопрос встречный. сможет ли MуSQL подготовит данные так, чтобы воспринимал это Altium, или потребуется промежуточная перегонка в ACCESS./ Если да. То все прелести теряются.

В смысле БД правильный. Вопрос только в одном. Будет ли эта база работать напрямую из оболочки Altium.

Если нет. Она станет не интересна для этой ветки форума.

Естественно. Видимо, Вы не очень ориентируетесь в базах данных, если задаете такие вопросы. Главное здесь - не MySQL, а альтиум. Т.е. сможет ли он работать не только с аксессом. Большинство БД могут быть связаны с прикладными программами с помощь стандартизированных интерфейсов, типа ODBC или JDBC.

 

Отчего же . в PCAD такое тоже есть. Там и FootPrint может содержать не одно о несколько посадочных.

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

 

Но расскажу еще об подводном камне.

в Altiume позволительно прямо в схеме или PCB модифицировать УГО или Footprint/

А при синхронизации из базы-- возьмется то, что там стоит. Бац и ошибка в проектировании.

Проходили :(

Проходили? И какие сделали выводы?

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

Если Вы сделали вывод, что нужно как можно чаще и безусловно синхронизировать проекты с базой, то это неправильно. База имеет право жить своей жизнью, она не должна знать об изменениях, проходящих во всех проектах, выполненных на ее основе (если должна, то это уже система типа PLM, гораздо более высокого уровня сложности, мы же рассматриваем систему PDM - ниже по классу). Однако, чтобы была возможность контролировать процессы изменений компонентов, мною выше была предложено поле версии компонента.

[Uladzimir 72]

То есть вы под библиотекой рассматриваете общий случай, где вывод на САПР, в частности altium это один из доступных вариантов

Так точно.

 

Принято.

Я посмотрел файлики .dblib и понял, что альтиум работает по-аналогии с остальными

Имено так. Но в стандартном выпадающем меню есть только Access и Excell

наводят на мысль о том, что альтиум работает не только с аксессом, но еще и через ODBC

и это есть. Подключается в отдельном окне. Но из-за отсутстия примеров не пользовался.

Вы наводите на мысль использовать именно эту связь подключения баз?

Ну, пикад, хотя бы у меня есть, посмотрю,

Не стоит. он умер. Просто поверьте это там было всегда

Проходили? И какие сделали выводы?

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

Если Вы сделали вывод, что нужно как можно чаще и безусловно синхронизировать проекты с базой, то это неправильно. База имеет право жить своей жизнью, она не должна знать об изменениях, проходящих во всех проектах, выполненных на ее основе (если должна, то это уже система типа PLM, гораздо более высокого уровня сложности, мы же рассматриваем систему PDM - ниже по классу). Однако, чтобы была возможность контролировать процессы изменений компонентов, мною выше была предложено поле версии компонента.

Ну нет. Просто можно апдейтит все не глядя, включая графику. Либо выбранные компоненты. Либо только отдельные параметры компонентов. Либо только всхем . Либо в PCB/ Короче все пожелания.

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

Апдейтили в моем примере не глядя все не я, а заказчики

[vitan 2]

Вы наводите на мысль использовать именно эту связь подключения баз?

Йаволь. Только так. Я там что-то видел про диск D:, этого быть не должно, думаю, это всем понятно.

 

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

Апдейтили в моем примере не глядя все не я, а заказчики

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

Я не понял, у Вас заказчики правят схему?

[Uladzimir 72]

Ну.можно и так. сказать. Это работа в группе. Их схема. Мои правки.

Вот картинка по базе, может для Вас интересна

 

В добавок. И базы у них собственные. Но тоже в Access

[jkrieger 0]

Нет, я не агитирую за бесплатные СУБД. Хотя, к примеру, MуSQL уже почти де-факто стандарт. Я против аксесса. Вы начали проект коллективной БД, да еще и с доступом через интернет. Как Вы думаете, сколько она продержится до первого падения? А будут ли довольны пользователи? Рассматривайте аксесс, как просто прогу из состава офиса. Тогда все станет на свои места, будете юзать его для мелких поделок в этом самом офисе, ну или дома, не далее.

Не вижу причин, по которым база Аццеса упадет из-за того что она на СВН лежит =) Наш Аццесс и не узнает об этом.

Довольство пользователей будет зависеть только от того насколько удобные формы мы сделаем =) Хотя если речь идет о лицензиях, то тут да, придется покупать профессиональный офис, самый дорогой.

 

Дело в другом. Что можно предложить взамен? То что к Альтиуму можно подцепить другие БД я уверен. Правда тоже не знаю как. Самое главное - обеспечить механизм репликации баз. В этом для меня самая большая загвоздка.

 

И позвольте мне небольшой оффтоп, Ацесс не просто програ из офиса, она из профессиональной версии офиса. Для мелких поделок хватит Екселя. А вот Аццесс может вполне заменить большинство систем электронного документооборота =)

 

[vitan 2]

Вот картинка по базе, может для Вас интересна

Спасибо, очень полезная для понимания альтиума картинка. Вот сразу бы.

 

Не вижу причин, по которым база Аццеса упадет из-за того что она на СВН лежит =) Наш Аццесс и не узнает об этом.

Довольство пользователей будет зависеть только от того насколько удобные формы мы сделаем =)

SVN ни при чем, понятно. Формы тоже ни при чем, поверьте. Довольны все будут, если все будет: а) просто; б) стабильно; в) помогать в работе (самое главное).

Аксесс будет не стабилен (глюкав). Это все перечеркнет.

 

Дело в другом. Что можно предложить взамен? То что к Альтиуму можно подцепить другие БД я уверен. Правда тоже не знаю как.

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

1. Соединять локальные альтиумы с интернетовской базой по какому-то протоколу поверх TCP/IP. Для примера, ментор умеет коннектиться к удаленной базе через HTTP. Про альтиум не знаю. Это модель, в которой большое значение имеет сервер.

2. Пытаться создавать реплики. Здесь менее важно, куда именно коннектиться, главное, чтобы было, куда (более децентрализованная модель).

 

Самое главное - обеспечить механизм репликации баз. В этом для меня самая большая загвоздка.

Оно и понятно. Это непростое дело. Я лично этим не занимался, но если что, попробую помочь по мере сил.

Могу сразу сказать, что даже при работе по централизованному варианту мне пришлось городить систему проверки компонентов с помощью специализированного софта, в котором есть возможности запуска процессов. И это заняло около двух месяцев. Что уж говорить, если баз будет несколько?!

 

И позвольте мне небольшой оффтоп, Ацесс не просто програ из офиса, она из профессиональной версии офиса. Для мелких поделок хватит Екселя. А вот Аццесс может вполне заменить большинство систем электронного документооборота =)

Поддержу. :) Вы хорошо разбираетесь в документообороте? Поверьте, аксесс его не заменит. В нем просто нет необходимых механизмов. Эксель же не надо сранивать с аксессом, это не СУБД, а вычислительная программа с некоторыми функциями связи с базами.

[jkrieger 0]

Аксесс будет не стабилен (глюкав). Это все перечеркнет.

А на чем основывается это утверждение? На общепринятом мнении что у МС все глюкаво? =)

Я считаю, что любое ПО не застраховано от ошибок. Так что тут скорее всего будет ничья.

 

А вот механизм репликации баз мы точно напишем хуже чем МС. В этом я не сомневаюсь.

 

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

[Uladzimir 72]

Довольны все будут, если все будет: а) просто; б) стабильно; в) помогать в работе (самое главное).

Аксесс будет не стабилен (глюкав). Это все перечеркнет.

 

Все пункт поддерживаю

Для примера, ментор умеет коннектиться к удаленной базе через HTTP. Про альтиум не знаю.

Умеет

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

Эксель калькулятор, а аксесс красивая оболочка для калькулятора :)

В первом, кроме просто записей и возможности бездумного копирования и размножения строк- ничего нет

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

 

 

 

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

Где то так. Но насколько я понимаю, и та база предполагает локальные версии?

На случай, когда бандиты сеть отрубили?