Uladzimir 80 13 октября, 2010 Опубликовано 13 октября, 2010 · Жалоба В моей БД компоненты лежат в одной таблице, но имеют поле, в котором записано, какой группе (библиотеке) они принадлежат. Замечательно. У меня тоже. но имеют поле, в котором записано, какой группе (библиотеке) они принадлежат. У меня достаточно названия УГО Чтобы поместить компонент на схему (точнее, поместить его УГО и добавить к нему атрибуты из БД), я выбираю в САПР так называемую библиотеку. Здесь слово "библиотека" носит уже чисто схемотехнический смысл, ибо она доступна из САПР и связана с САПР. Связь группы компонентов в БД и САПР обеспечивают те самые файлики, в которых галочками настраивается видимость атрибутов (и другие вещи). Все тоже. Только открывается нужная таблица, в ней находится нужный компонент. Подключение УГО, внесение в УГО параметров из таблицы и подключение к УГО Footprint производится по ссылкам базы и производится вставка в схему. Такой УГО с параметрами превращается в полноценный компонент. В моем случае САПР ищет УГО в местах, где хранятся УГО, т.е. в библиотеках УГО. Тоже самое только плюс и Footprint Точно так же САПР печатных плат ищет футпринты - по путям с библиотеками футпринтов. Соответствие же путей поиска УГО и библиотек компонентов, находящихся в БД, задается в тех же файлах настройки Тоже Footprint вставляется напрямую на плату. А так уже ссылка есть на схеме и оттуда берется Как я понял, в альтиуме нет разделения между компонентом и его УГО, т.е. информация об этом хранится где-то в бинарном виде в файликах во внутреннем формате альтиума. Если так, то для альтиума понятие библиотеки УГО вырождается в понятие библиотеки компонентов. Нет. Просто на схему попадает не голый УГО, а уже с параметрами, как я писал выше-- делая его полнокровным компонентом. Тем не менее, предлагаю отделять понятия библиотек компонентов, библиотек УГО и библиотек футпринтов. Для альтиума два последних, очевидно, будут просто копировать структуру библиотек компонентов, но для других САПР будет большая польза. Это, если я правильно понял, как работает альтиум. Алтиум позволяет и так и этак. Я именно за разделения библиотек компонентов (это запись в таблице), библиотек УГО и библиотек футпринтов. Таким образом, библиотека компонентов - это некоторая сущность в БД. Я бы сказал БИБЛИОТЕКА да. и не путать с библиотеками УГО и библиотек футпринтов Я плохо ориентируюсь в альтиуме, но думаю, что всех смущают файлики .dblib. Видимо, все думают о них, как о библиотеках. Я так понял, это файлики, настраивающие видимость атрибутов, но сами не содержащие инфы о компонентах. Это так? Нет это не библиотека. Там указано только какую базу подключить, какие параметры из нее взять, куда их подставить, и нужно ли их отобразить. То есть своеобразный Ini файл Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
vitan 2 13 октября, 2010 Опубликовано 13 октября, 2010 · Жалоба Отлично. Полнейший консенсус. :) Абсолютно никаких расхождений с поведением ментора и кейденса. Все тоже. Только открывается нужная таблица Вот здесь надо будет открывать не таблицу, а запрос. Альтиум видит запросы? Если не видит, то сервер может динамически генерить таблицы для него. В таблицу будут попадать поля, необходимые для схемотехника. После этого поведение этой таблицы будет настраиваться файликами .dblib. Просто, бывают такие проги, которые не видят запросов, а видят только таблицы. Если альтиум видит запросы, то все в порядке. Библиотекой компонентов в этом случае будет запрос, как у всех нормальных людей. :) Точнее, этот запрос будет отражать содержимое этой библиотеки и называться будет так же, как называется сама библиотека (компонентов). Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Uladzimir 80 13 октября, 2010 Опубликовано 13 октября, 2010 · Жалоба Отлично. Полнейший консенсус. :) Абсолютно никаких расхождений с поведением ментора и кейденса. Вот здесь надо будет открывать не таблицу, а запрос. Альтиум видит запросы? Если не видит, то сервер может динамически генерить таблицы для него. В таблицу будут попадать поля, необходимые для схемотехника. После этого поведение этой таблицы будет настраиваться файликами .dblib. Просто, бывают такие проги, которые не видят запросов, а видят только таблицы. Если альтиум видит запросы, то все в порядке. Библиотекой компонентов в этом случае будет запрос, как у всех нормальных людей. :) Точнее, этот запрос будет отражать содержимое этой библиотеки и называться будет так же, как называется сама библиотека (компонентов). Вообще видит. Я правда через запросы не работал. Запросы видит также как таблицы. И именно в запросах можно отделять резисторы от конденсаторов, и так далее. Каждый запрос видится в панели как независимая библиотека. Так что Алтиум тоже для нормальных людей :) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
vitan 2 13 октября, 2010 Опубликовано 13 октября, 2010 · Жалоба Прекрасно! Вот только поясните все-таки вот эти слова: Вот тут я категорически против. Хотя раньше был на этой позиции особенно в свете вот этих слов: Я именно за разделения библиотек компонентов (это запись в таблице), библиотек УГО и библиотек футпринтов. Вы не хотите создавать библиотеки УГО? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Uladzimir 80 13 октября, 2010 Опубликовано 13 октября, 2010 · Жалоба Это разночтения понимания слова библиотека. Я за хранение УГО в индивидуальном файле. Формально это тоже библиотека, состоящая из одного УГО Тоже касается и Footprint Единственное исключение-- в одном файле можно держать 4 Footprint -- Для плотного нормального, свободного и рекомендуемого. Ну скажем еще пользовательского. Ну скажем еще для вертикальной установки. Но смысл понятен. Это один Footprint для разных типов монтажа. Тоже касается и Sim моделей. То есть без библиотек ни как. Иначе не вставишь в алтиум. Но это не библиотеки содержащие в одном файле тыщи разнородных УГО и т.п. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
vitan 2 13 октября, 2010 Опубликовано 13 октября, 2010 · Жалоба Я за хранение УГО в индивидуальном файле. Формально это тоже библиотека, состоящая из одного УГО Понял. Т.о. нужны ссылки в базе на УГО компонента. И, следовательно, группы ссылок в базе, т.е. библиотеки УГО в базе. Нет возражений? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Uladzimir 80 13 октября, 2010 Опубликовано 13 октября, 2010 · Жалоба Т.о. нужны ссылки в базе на УГО компонента. В точку. У точню . в таблице базы. Соответственно для атриума можно и в запросе. И, следовательно, группы ссылок в базе, Группы УГО зачем?. Компоненту соответствует один УГО. То есть ссылка на УГО единственная. Если есть несколько Уго, которые можно сопоставить компоненту--в алтиуме поддерживаются Альтернативные изображения УГО Альтернативные изображения УГО хранятся вместе с основным, и не различаются по обозначению. В схемотехническом редакторе можно выбрать вид альтернативного изображения. В принципе его можно и предопределить и в базе (параметр Mode)-- но это лишнее. При таком подходе у схемотехника, выбравшего компонент, есть выбор использования в схеме любого альтернативного изображения УГО без повторного обращения к БАЗЕ Хотя возможен вариант ссылок в базе и на несколько УГО для одного компонента. Но мне он не нравится т.е. библиотеки УГО в базе. Нет возражений? Ну я бы так сказал библиотеки УГО в БАЗЕ. Ну то есть к БАЗЕ относим не только файлы таблиц , но и все файлы библиотек УГО, посадочных мест, моделей и.... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jkrieger 0 13 октября, 2010 Опубликовано 13 октября, 2010 (изменено) · Жалоба Правильно, что начали с терминов. Только термины типа "база данных", "таблица", "запрос" и т.п., имхо обсуждать нечего, это общеупотребительные вещи. Даже "компонент" имхо обсуждать не надо, ибо всем понятно, что это - то, что можно взять и подержать в руках, а никак не запись в БД. Что такое "базы для нескольких САПР"? Мы так и не договорились о терминах... Я просто не понимаю эту фразу, честно. Понятно то понятно, но вот мы же с вами давеча и не понимали друг друга. Потому и решил привести эти определения. Итак, очевидно, пока обсуждается система с функциями хранения информации об эл. компонентах и топологических элементах и с возможностями одновременной работы нескольких пользователей, которые подключаются к ней САПРами (разными). База располагается на сервере в интернете, планируется создание клиента для изменения данных в базе (возможно, веб-клиента). Для компонентов должен быть параметрический поиск. Склада и закупок нет. Так? Если да, то надо определить, по какому интерфейсу будет к БД коннектиться САПР. Позвольте высказать свое видение. САПР будет подключаться к рабочей БД (локальная копия той что в инете) так как оно (САПР) умеет. У меня скорее всего будет к аццесовской mdb подключаться. Далее. Сама общая БД будет например на той же MySQL где-то на сервере. Общаться с этой БД можно будет при помощи клиента через http. Основная задача клиента, как я понимаю, это получить новые и обновленные записи из всех таблиц в общей БД. И показать их пользователю. Еси пользователь согласен с изменениями, он записывает их в свою рабочую копию, если нет, то его данные не изменяются (позволяется небольшая рассинхронизация). В случае если будет прямой доступ к общей БД (а такие хостинги все таки существуют), то клиент может и не понадобиться - его роль сможет выполнять СУБД. Ну а добавление компонентов можно сделать хоть через веб интерфейс, хоть опять же через клиента или запросы в СУБД. По поводу склада и учета. По-моему тут его не может быть. Вы собираетесь хранить в общей БД (той что на сервере в инете) свой склад? Кроме вас ведь никому не надо оно. Ну а связать вашу складскую БД и БД для САПР по-моему достаточно просто. noxius, скажите тм есть возможность подключаться к БД напрямую? Чтобы указал хост:порт отправлять запросы? Изменено 13 октября, 2010 пользователем Jack Krieger Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Uladzimir 80 13 октября, 2010 Опубликовано 13 октября, 2010 · Жалоба Позвольте высказать свое видение. И я выскажу САПР будет подключаться к рабочей БД (локальная копия той что в инете) так как оно (САПР) умеет. У меня скорее всего будет к аццесовской mdb подключаться. САПР может подключиться и к локальной БД (слепка БД из инета) И к БД из интернета. Этому никто не мешает и пользователь сам может определить с какой ему работать . Это на любителя и требование к общей БД не ограничивает Далее. Сама общая БД будет например на той же MySQL где-то на сервере. Общаться с этой БД можно будет при помощи клиента через http. Основная задача клиента, как я понимаю, это получить новые и обновленные записи из всех таблиц в общей БД. И показать их пользователю. Еси пользователь согласен с изменениями, он записывает их в свою рабочую копию, если нет, то его данные не изменяются (позволяется небольшая рассинхронизация). В случае если будет прямой доступ к общей БД (а такие хостинги все таки существуют), то клиент может и не понадобиться - его роль сможет выполнять СУБД. Я думаю это просто получить по запросу выдать модификации за указанный период Сложнее с файлами библиотек. В этом смысле нужно держать и ссылки на пути, где лежат файлы УГО и прочего, чтобы знать, что забирать По поводу склада и учета. По-моему тут его не может быть. Вы собираетесь хранить в общей БД (той что на сервере в инете) свой склад? Кроме вас ведь никому не надо оно. Ну а связать вашу складскую БД и БД для САПР по-моему достаточно просто. Да. это индивидуальное, но стоило бы иметь пустую заготовку, как рекомендацию Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Krys 2 14 октября, 2010 Опубликовано 14 октября, 2010 · Жалоба Да. это индивидуальное, но стоило бы иметь пустую заготовку, как рекомендациюВот я об этом и твержу. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
noxius 0 14 октября, 2010 Опубликовано 14 октября, 2010 · Жалоба noxius, скажите тм есть возможность подключаться к БД напрямую? Чтобы указал хост:порт отправлять запросы? По словам службы поддержки такая возможность есть... у самого пока не получилось.. могу дать host dbname login pass далее.. на большинстве хостингах поддерживается только MySQL, для работы удаленно с .mdb нужен либо WIndows сервер либо чтото горадить(пока еще не разобрался что и как можно сделать на nix сервере) насчет html клиента .. не нравится мне такое название... -) HyperText Markup Language — язык разметки гипертекста .. не умеет html работать с базами данных.. нужно на PHP писать либо на чем-то другом..(html можно и нужно использовать но только для придания "красоты" интерфейсу(внешнему виду клиента)) может называть клиента Web-клиентом? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
vitan 2 14 октября, 2010 Опубликовано 14 октября, 2010 · Жалоба Группы УГО зачем?. Компоненту соответствует один УГО. То есть ссылка на УГО единственная. Хотя возможен вариант ссылок в базе и на несколько УГО для одного компонента. Но мне он не нравится Ээээ... А как Вы собираетесь рисовать процессор о тысяче ногах? Такое УГО на лист не влезет. Компонент в общем случае имеет несколько УГО, причем могут встречаться как разделенные УГО, так и альтернативные, которые тоже могут быть разделенными. Лично у меня нет строгого указания в БД, какое УГО альтернативное, а какое - просто вторая часть основного, все они перечислены через запятую, и выводятся в САПР, где рисовальщик принимает решение. Хорошо, что заговорили, надо будет это поправить... Теперь про группировку. Разве не нормально группировать, скажем, УГО резисторов в отдельную группу, УГО конденсаторов - в отдельную, и т.д.? Вы же сами говорили, что храните в БД префиксы рефдесов. Это как раз отлично отражает разделение УГО на библиотеки УГО. При этом для каждой библиотеки УГО в БД можно будет задать этот префикс, да и много чего другого. Кроме того, сами файлы можно будет раскладывать по папочкам в соответствии с названиями библиотек УГО, что прибавит порядка на диске. Ну я бы так сказал библиотеки УГО в БАЗЕ. Ну то есть к БАЗЕ относим не только файлы таблиц , но и все файлы библиотек УГО, посадочных мест, моделей и.... Есть предложение заменить слово "БАЗА" словом "система". А то кто-то может случайно регистр попутать. Я вот, только раза с третьего понял фишку... :) Понятно то понятно, но вот мы же с вами давеча и не понимали друг друга. Потому и решил привести эти определения. Ладно, если все считают это полезным, то я не против. Основная задача клиента, как я понимаю, это получить новые и обновленные записи из всех таблиц в общей БД. И показать их пользователю. Еси пользователь согласен с изменениями, он записывает их в свою рабочую копию, если нет, то его данные не изменяются (позволяется небольшая рассинхронизация). Это клиент, имеющий функции синхронизации. Весьма специфическая прога, не буду повторяться. В случае если будет прямой доступ к общей БД (а такие хостинги все таки существуют), то клиент может и не понадобиться - его роль сможет выполнять СУБД. Не запутывайте читающих. СУБД и клиент - вещи, стоящие на противоположных концах цепочки. СУБД никогда не сможет исполнять функции клиента просто потому, что она сама не знает, что делать с данными. Она только исполняет команды клиента. Ну а добавление компонентов можно сделать хоть через веб интерфейс, хоть опять же через клиента или запросы в СУБД. Правильно. Остается вопрос: кто в описанной модели с аксессом будет выполнять добавление и изменение компонентов в основной БД? Тот же клиент? По словам службы поддержки такая возможность есть... у самого пока не получилось.. могу дать host dbname login pass может называть клиента Web-клиентом? Большинство хостингов как раз предоставляют MYSQL+PHP. Это уже чуть ли не стандарт для интернета. Конечно, web-клиент. Я уже давно так и называю... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Uladzimir 80 14 октября, 2010 Опубликовано 14 октября, 2010 · Жалоба Ээээ... А как Вы собираетесь рисовать процессор о тысяче ногах? Такое УГО на лист не влезет. Компонент в общем случае имеет несколько УГО, причем могут встречаться как разделенные УГО, так и альтернативные, которые тоже могут быть разделенными. Естественно я и рисую. Такое УГО содержит несколько PART (частей). Все PART-- Неделимое целое УГО. В схемотехническом редакторе есть возможность выбора любого PART УГО. Более того. Смотрите мелкую логику. там многие PART взаимозаменяемы и на PCB делается SWAP. И это все уже без участия базы. Отдельно рисовать PART и хранить их нет необходимости, да и такое подключение не поддерживается в Altium. И что-то мне говорит , что и в других схемотехнических редакторах тоже Лично у меня нет строгого указания в БД, какое УГО альтернативное, а какое - просто вторая часть основного, все они перечислены через запятую, и выводятся в САПР, где рисовальщик принимает решение. Хорошо, что заговорили, надо будет это поправить... Вот тут поймите. Каждое альтернативное изображение тоже может содержать PART. Но не в этом дело. Вот на простом примере УГО Светодиода. Основное понятно. Альтернативное-- ото я его тело просто закрашу красным для красного светодоиода, зеленым для зеленого. .... Но все остальное--- таже. Это только удобство представления информации на схеме. Ну схему всегда вставляется информация обо всех альтернативных УГО и их PART (это все хранится в одном месте, файле, библиотеке УГО и имеет ОДНО название). и это одна ссылка. Схемотехник после вставки на схему уже обладает всей информацией и может самостоятельно использовать любое УГО и их PART. Теперь про группировку. Разве не нормально группировать, скажем, УГО резисторов в отдельную группу, УГО конденсаторов - в отдельную, и т.д.? Вы же сами говорили, что храните в БД префиксы рефдесов. Это как раз отлично отражает разделение УГО на библиотеки УГО. При этом для каждой библиотеки УГО в БД можно будет задать этот префикс, да и много чего другого. Кроме того, сами файлы можно будет раскладывать по папочкам в соответствии с названиями библиотек УГО, что прибавит порядка на диске. В общем я так и раскладываю :) Есть предложение заменить слово "БАЗА" словом "система". А то кто-то может случайно регистр попутать. Я вот, только раза с третьего понял фишку... Ну вот и я о том же Что БАЗА и база-- разные вещи. Сокращенно можно использовать. главное, чтоб все понимали, что под этим подразумевается. Формально у нас не проста БАЗА, как хранилище, а именно БИБЛИОТЕКА (для пользователей САПР) . Где по каталожному номеру можно легко и просто найти нужный элемент. И даже не библиотека, а и библиотекарши, которые по запросам доставляют нужную книжечку. Поэтому можно типа Система хранения и автоматизированного поиска .... СХАВ по абревиатуре. Но над красивым и броским названием нужно еще работать Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
vitan 2 14 октября, 2010 Опубликовано 14 октября, 2010 · Жалоба Все PART-- Неделимое целое УГО. В схемотехническом редакторе есть возможность выбора любого PART УГО. Более того. Смотрите мелкую логику. там многие PART взаимозаменяемы и на PCB делается SWAP. И это все уже без участия базы. Отдельно рисовать PART и хранить их нет необходимости, да и такое подключение не поддерживается в Altium. И что-то мне говорит , что и в других схемотехнических редакторах тоже А вот и нет. У всех по-разному. Вот, в менторе, например, один файл - одно УГО. Из нескольких УГО можно сочинять сложные УГО. Поэтому я считаю, что указывать для компонента нужно все его УГО (чтобы сохранить сапронезависимость). Ну схему всегда вставляется информация обо всех альтернативных УГО и их PART (это все хранится в одном месте, файле, библиотеке УГО и имеет ОДНО название). и это одна ссылка. Схемотехник после вставки на схему уже обладает всей информацией и может самостоятельно использовать любое УГО и их PART. Таким образом, в БД должны быть перечислены все УГО компонента. УГО будут взяты из библиотеки УГО, которая закреплена за компонентом (точнее, за библиотекой компонентов). А вот ссылки на сами файлы с УГО должны формироваться по правилам, которые зависят от конкретного САПР. Например, для альтиума, в БД должна отработать некая хранимая процедура, которая посмотрит на список всех УГО компонента и на основе него сформирует название файла, в котором лежат все эти УГО. Для другого САПР будет сформирована другая строка, в моем случае это будет просто перечисление через запятую. Выбор текущего САПР должен быть заложен в настройках. Нет возражений? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Sanches 0 14 октября, 2010 Опубликовано 14 октября, 2010 · Жалоба надеюсь что задам вопрос по теме организации БД в AD:) . Начал делать БД для своего отдела и все вроде бы шло неплохо, но столкнулся с такой проблемой: допустим есть УГО на NPN транзистор (1-база,2-коллектор,3-эмиттер), и есть футпринты. Хочу забить в базу несколько транзисторов разного типа, а цоколевка у всех корпусов разная (у одних 1-коллектор, у вторых 3-коллектор и т.п.). получаеца чтобы при трансляции в pcbdoc компонент правильно "связался" необходимо в sch редакторе заходить в свойства компонента и переопределять пины. Есть ли возможность как то в самой базе определить какой пин уго соответствует паду корпуса? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться