[Uladzimir 80]

В моей БД компоненты лежат в одной таблице, но имеют поле, в котором записано, какой группе (библиотеке) они принадлежат.

Замечательно. У меня тоже.

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

У меня достаточно названия УГО

Чтобы поместить компонент на схему (точнее, поместить его УГО и добавить к нему атрибуты из БД), я выбираю в САПР так называемую библиотеку. Здесь слово "библиотека" носит уже чисто схемотехнический смысл, ибо она доступна из САПР и связана с САПР. Связь группы компонентов в БД и САПР обеспечивают те самые файлики, в которых галочками настраивается видимость атрибутов (и другие вещи).

Все тоже. Только открывается нужная таблица, в ней находится нужный компонент. Подключение УГО, внесение в УГО параметров из таблицы и подключение к УГО Footprint производится по ссылкам базы и производится вставка в схему. Такой УГО с параметрами превращается в полноценный компонент.

В моем случае САПР ищет УГО в местах, где хранятся УГО, т.е. в библиотеках УГО.

Тоже самое только плюс и Footprint

Точно так же САПР печатных плат ищет футпринты - по путям с библиотеками футпринтов. Соответствие же путей поиска УГО и библиотек компонентов, находящихся в БД, задается в тех же файлах настройки

Тоже Footprint вставляется напрямую на плату. А так уже ссылка есть на схеме и оттуда берется

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

Нет. Просто на схему попадает не голый УГО, а уже с параметрами, как я писал выше-- делая его полнокровным компонентом.

Тем не менее, предлагаю отделять понятия библиотек компонентов, библиотек УГО и библиотек футпринтов. Для альтиума два последних, очевидно, будут просто копировать структуру библиотек компонентов, но для других САПР будет большая польза. Это, если я правильно понял, как работает альтиум.

Алтиум позволяет и так и этак. Я именно за разделения библиотек компонентов (это запись в таблице), библиотек УГО и библиотек футпринтов.

Таким образом, библиотека компонентов - это некоторая сущность в БД.

Я бы сказал БИБЛИОТЕКА да. и не путать с библиотеками УГО и библиотек футпринтов

Я плохо ориентируюсь в альтиуме, но думаю, что всех смущают файлики .dblib.

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

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

То есть своеобразный Ini файл

[vitan 2]

Отлично. Полнейший консенсус. :) Абсолютно никаких расхождений с поведением ментора и кейденса.

 

Все тоже. Только открывается нужная таблица

Вот здесь надо будет открывать не таблицу, а запрос.

Альтиум видит запросы?

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

Просто, бывают такие проги, которые не видят запросов, а видят только таблицы.

Если альтиум видит запросы, то все в порядке.

Библиотекой компонентов в этом случае будет запрос, как у всех нормальных людей. :)

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

[Uladzimir 80]

Отлично. Полнейший консенсус. :) Абсолютно никаких расхождений с поведением ментора и кейденса.

 

 

Вот здесь надо будет открывать не таблицу, а запрос.

Альтиум видит запросы?

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

Просто, бывают такие проги, которые не видят запросов, а видят только таблицы.

Если альтиум видит запросы, то все в порядке.

Библиотекой компонентов в этом случае будет запрос, как у всех нормальных людей. :)

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

Вообще видит.

Я правда через запросы не работал.

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

Так что Алтиум тоже для нормальных людей :)

[vitan 2]

Прекрасно!

Вот только поясните все-таки вот эти слова:

 

Вот тут я категорически против.

Хотя раньше был на этой позиции

особенно в свете вот этих слов:

Я именно за разделения библиотек компонентов (это запись в таблице), библиотек УГО и библиотек футпринтов.

 

Вы не хотите создавать библиотеки УГО?

[Uladzimir 80]

Это разночтения понимания слова библиотека.

Я за хранение УГО в индивидуальном файле. Формально это тоже библиотека, состоящая из одного УГО

Тоже касается и Footprint

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

Тоже касается и Sim моделей.

 

То есть без библиотек ни как. Иначе не вставишь в алтиум.

Но это не библиотеки содержащие в одном файле тыщи разнородных УГО и т.п.

[vitan 2]

Я за хранение УГО в индивидуальном файле. Формально это тоже библиотека, состоящая из одного УГО

Понял.

Т.о. нужны ссылки в базе на УГО компонента. И, следовательно, группы ссылок в базе, т.е. библиотеки УГО в базе.

Нет возражений?

[Uladzimir 80]

Т.о. нужны ссылки в базе на УГО компонента.

В точку. У точню . в таблице базы. Соответственно для атриума можно и в запросе.

И, следовательно, группы ссылок в базе,

Группы УГО зачем?. Компоненту соответствует один УГО.

То есть ссылка на УГО единственная.

Если есть несколько Уго, которые можно сопоставить компоненту--в алтиуме поддерживаются Альтернативные изображения УГО

Альтернативные изображения УГО хранятся вместе с основным, и не различаются по обозначению.

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

В принципе его можно и предопределить и в базе (параметр Mode)-- но это лишнее.

При таком подходе у схемотехника, выбравшего компонент, есть выбор использования в схеме любого альтернативного изображения УГО без повторного обращения к БАЗЕ

 

Хотя возможен вариант ссылок в базе и на несколько УГО для одного компонента. Но мне он не нравится

т.е. библиотеки УГО в базе.

Нет возражений?

Ну я бы так сказал библиотеки УГО в БАЗЕ.

Ну то есть к БАЗЕ относим не только файлы таблиц , но и все файлы библиотек УГО, посадочных мест, моделей и....

[jkrieger 0]

Правильно, что начали с терминов.

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

Даже "компонент" имхо обсуждать не надо, ибо всем понятно, что это - то, что можно взять и подержать в руках, а никак не запись в БД.

 

Что такое "базы для нескольких САПР"? Мы так и не договорились о терминах...

Я просто не понимаю эту фразу, честно.

 

Понятно то понятно, но вот мы же с вами давеча и не понимали друг друга. Потому и решил привести эти определения.

 

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

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

Так?

 

Если да, то надо определить, по какому интерфейсу будет к БД коннектиться САПР.

 

Позвольте высказать свое видение. САПР будет подключаться к рабочей БД (локальная копия той что в инете) так как оно (САПР) умеет. У меня скорее всего будет к аццесовской mdb подключаться.

 

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

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

Ну а добавление компонентов можно сделать хоть через веб интерфейс, хоть опять же через клиента или запросы в СУБД.

 

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

 

noxius, скажите тм есть возможность подключаться к БД напрямую? Чтобы указал хост:порт отправлять запросы?

 

Изменено 13 октября, 2010 пользователем Jack Krieger

[Uladzimir 80]

Позвольте высказать свое видение.

И я выскажу

САПР будет подключаться к рабочей БД (локальная копия той что в инете) так как оно (САПР) умеет. У меня скорее всего будет к аццесовской mdb подключаться.

САПР может подключиться и к локальной БД (слепка БД из инета) И к БД из интернета.

Этому никто не мешает и пользователь сам может определить с какой ему работать . Это на любителя и требование к общей БД не ограничивает

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

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

Я думаю это просто получить по запросу выдать модификации за указанный период

Сложнее с файлами библиотек. В этом смысле нужно держать и ссылки на пути, где лежат файлы УГО и прочего, чтобы знать, что забирать

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

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

[Krys 2]

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

Вот я об этом и твержу.

 

[noxius 0]

noxius, скажите тм есть возможность подключаться к БД напрямую? Чтобы указал хост:порт отправлять запросы?

 

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

могу дать host dbname login pass

 

далее.. на большинстве хостингах поддерживается только MySQL,

для работы удаленно с .mdb нужен либо WIndows сервер либо чтото горадить(пока еще не разобрался что и как можно сделать на nix сервере)

 

насчет html клиента .. не нравится мне такое название... -) HyperText Markup Language — язык разметки гипертекста .. не умеет html работать с базами данных.. нужно на PHP писать либо на чем-то другом..(html можно и нужно использовать но только для придания "красоты" интерфейсу(внешнему виду клиента))

может называть клиента Web-клиентом?

[vitan 2]

Группы УГО зачем?. Компоненту соответствует один УГО.

То есть ссылка на УГО единственная.

 

Хотя возможен вариант ссылок в базе и на несколько УГО для одного компонента. Но мне он не нравится

Ээээ... А как Вы собираетесь рисовать процессор о тысяче ногах? Такое УГО на лист не влезет.

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

Лично у меня нет строгого указания в БД, какое УГО альтернативное, а какое - просто вторая часть основного, все они перечислены через запятую, и выводятся в САПР, где рисовальщик принимает решение. Хорошо, что заговорили, надо будет это поправить...

 

Теперь про группировку. Разве не нормально группировать, скажем, УГО резисторов в отдельную группу, УГО конденсаторов - в отдельную, и т.д.?

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

 

Ну я бы так сказал библиотеки УГО в БАЗЕ.

Ну то есть к БАЗЕ относим не только файлы таблиц , но и все файлы библиотек УГО, посадочных мест, моделей и....

Есть предложение заменить слово "БАЗА" словом "система". А то кто-то может случайно регистр попутать. Я вот, только раза с третьего понял фишку... :)

 

Понятно то понятно, но вот мы же с вами давеча и не понимали друг друга. Потому и решил привести эти определения.

Ладно, если все считают это полезным, то я не против.

 

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

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

 

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

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

 

Ну а добавление компонентов можно сделать хоть через веб интерфейс, хоть опять же через клиента или запросы в СУБД.

Правильно.

 

Остается вопрос: кто в описанной модели с аксессом будет выполнять добавление и изменение компонентов в основной БД? Тот же клиент?

 

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

могу дать host dbname login pass

 

может называть клиента Web-клиентом?

Большинство хостингов как раз предоставляют MYSQL+PHP. Это уже чуть ли не стандарт для интернета.

Конечно, web-клиент. Я уже давно так и называю...

[Uladzimir 80]

Ээээ... А как Вы собираетесь рисовать процессор о тысяче ногах? Такое УГО на лист не влезет.

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

Естественно я и рисую. Такое УГО содержит несколько PART (частей). Все PART-- Неделимое целое УГО. В схемотехническом редакторе есть возможность выбора любого PART УГО. Более того. Смотрите мелкую логику. там многие PART взаимозаменяемы и на PCB делается SWAP.

И это все уже без участия базы.

Отдельно рисовать PART и хранить их нет необходимости, да и такое подключение не поддерживается в Altium. И что-то мне говорит , что и в других схемотехнических редакторах тоже

Лично у меня нет строгого указания в БД, какое УГО альтернативное, а какое - просто вторая часть основного, все они перечислены через запятую, и выводятся в САПР, где рисовальщик принимает решение. Хорошо, что заговорили, надо будет это поправить...

Вот тут поймите. Каждое альтернативное изображение тоже может содержать PART.

Но не в этом дело.

Вот на простом примере УГО Светодиода. Основное понятно. Альтернативное-- ото я его тело просто закрашу красным для красного светодоиода, зеленым для зеленого. .... Но все остальное--- таже. Это только удобство представления информации на схеме.

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

Теперь про группировку. Разве не нормально группировать, скажем, УГО резисторов в отдельную группу, УГО конденсаторов - в отдельную, и т.д.?

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

В общем я так и раскладываю :)

Есть предложение заменить слово "БАЗА" словом "система". А то кто-то может случайно регистр попутать. Я вот, только раза с третьего понял фишку...

Ну вот и я о том же Что БАЗА и база-- разные вещи. Сокращенно можно использовать. главное, чтоб все понимали, что под этим подразумевается.

Формально у нас не проста БАЗА, как хранилище, а именно БИБЛИОТЕКА (для пользователей САПР) . Где по каталожному номеру можно легко и просто найти нужный элемент.

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

Поэтому можно типа Система хранения и автоматизированного поиска .... СХАВ по абревиатуре.

Но над красивым и броским названием нужно еще работать

[vitan 2]

Все PART-- Неделимое целое УГО. В схемотехническом редакторе есть возможность выбора любого PART УГО. Более того. Смотрите мелкую логику. там многие PART взаимозаменяемы и на PCB делается SWAP.

И это все уже без участия базы.

Отдельно рисовать PART и хранить их нет необходимости, да и такое подключение не поддерживается в Altium. И что-то мне говорит , что и в других схемотехнических редакторах тоже

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

 

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

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

Выбор текущего САПР должен быть заложен в настройках.

Нет возражений?

 

[Sanches 0]

надеюсь что задам вопрос по теме организации БД в AD:) . Начал делать БД для своего отдела и все вроде бы шло неплохо, но столкнулся с такой проблемой: допустим есть УГО на NPN транзистор (1-база,2-коллектор,3-эмиттер), и есть футпринты. Хочу забить в базу несколько транзисторов разного типа, а цоколевка у всех корпусов разная (у одних 1-коллектор, у вторых 3-коллектор и т.п.). получаеца чтобы при трансляции в pcbdoc компонент правильно "связался" необходимо в sch редакторе заходить в свойства компонента и переопределять пины. Есть ли возможность как то в самой базе определить какой пин уго соответствует паду корпуса?