Uladzimir 80 29 сентября, 2010 Опубликовано 29 сентября, 2010 · Жалоба Владимир, что такое топологический компонент? Кстати компоненты, которые вы привели в пример случаев с отсутствием Manufacturer или ManufacturerNumber я даже не знаю в какую из групп (таблиц) отнести. А значит для них будет отдельная группа, где можно будет сделать исключение из общих правил. Контрольная точка, проводная перемычка, топологическая кнопка ... Примеры с отсутствием-- пожалуйста, резисторы, конденсаторы советского производства, на которые указывается только ТУ Чтобы не было одинаковых номеров, клиент БД должен проверять их перед записью. Как сделано в Альтиуме мне интересно только теоретически. Я его ни разу в глаза не видел. Но пытаюсь обобщить, так сказать... В том-то и дело, что _это не компоненты_! Компоненты Вы можете взять и подержать в руках. А это - некие конструктивно-топологические элементы рисунка на печатной плате. У них другая природа и другие характеристики. Поэтому мешать их с компонентами нельзя. Но, т.к. они нужны для рисования, то для них тоже нужна своя библиотека. В аксесе указывается запрет повторов. Оно не даст. По крайней мере в таблице Но если ключевое поле формируется из двух или более параметров-- клинч. Каждый параметр в отдельности может иметь совпадения, но результат объединения -- нет. Как это сделать а Access не знаю. Я не большой специалист Про топологические-- принято в отдельные. На них ни перечня ни покупных делать не надо Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
тау 31 29 сентября, 2010 Опубликовано 29 сентября, 2010 · Жалоба Но если ключевое поле формируется из двух или более параметров-- клинч. Каждый параметр в отдельности может иметь совпадения, но результат объединения -- нет. Как это сделать а Access не знаю. Я не большой специалист ключевое поле из нескольких полей делается так: редактируете "таблица в режиме конструктора" ; выделяете насколько строк где содержатся интересующие Вас поля при нажатой клавише CTRL; не отпуская CTRL правой клавишей мыши входите в контекстное меню и выбираете в нем "ключевое поле". Всё- эти поля станут общим ключом, не допускающим совокупных совпадений по всем ключевым полям. Будет ли съедобна такая таблица для альтиума - не знаю. Он любит вроде бы одно ключевое поле. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Uladzimir 80 29 сентября, 2010 Опубликовано 29 сентября, 2010 · Жалоба Спасибо попробую В алтиуме тоже можно задавать по куче параметров. Там ниже окно с построителем выражений Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
vitan 2 29 сентября, 2010 Опубликовано 29 сентября, 2010 · Жалоба Что касаемо полей в основной таблице компонентов, то могу посоветовать добавить следующие. - ROHS. Лучше не просто "да-нет", а выбирать из справочника. Их там может быть несколько вариантов, если почитать. Это нужно для быстрого понимания, как паять. - Поставщик. (вроде, не было). Ссылка на постащика в справочнике поставщиков. Для генерации ВП. - Ревизия. Лично у меня принята система, аналогичная CVS, где ревизии растут отдельно для каждого компонента. При очередном изменении юзеру выводится предупреждение, что ревизия будет инкрементирована, и выводится окно, в которое он записывает текст. Текст попадает в следующее поле (после проверки на пустую строку). - Комментарий к ревизии. Строка. Я так понял, альтиум заточен под SVN, но это не проблема, в этом случае нужно менять ревизию при каждом действии с компонентами. Это очень полезная вещь. На основе этого можно будет потом сделать нормальную коллективную работу с базой. И еще выводить историю изменений компонента. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jkrieger 0 29 сентября, 2010 Опубликовано 29 сентября, 2010 (изменено) · Жалоба тау, большое спасибо! Я чувствовал, что так возможно сделать, но не знал как. Теперь проблемы с идентификацией компонента и репликацией баз быть не должно. В альтиуме следует применять для связи строку: [Manufacturer] = '{Manufacturer}' AND [Manufacturer Number] = '{Manufacturer Number}' vitan, так как это база не для склада, то мы не вводим поля вроде Поставщик или Цена. Ну а строить систему контроля версий внутри БД думаю тоже будет накладно. Это немного не то, что предлагает Altium для SVN. Изменено 29 сентября, 2010 пользователем Jack Krieger Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
vitan 2 29 сентября, 2010 Опубликовано 29 сентября, 2010 · Жалоба vitan, так как это база не для склада, то мы не вводим поля вроде Поставщик или Цена. Ну а строить систему контроля версий внутри БД думаю тоже будет накладно. Это немного не то, что предлагает Altium для SVN. Да, про цену я молчу. А поставщика советую только для генерации КД, никак не для заказов и бухгалтерии. Про ревизию я уверен, что, если у Вас дело дойдет до коллективной работы с базой, то это делать придется, и SVN от Альтиума не поможет. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Uladzimir 80 29 сентября, 2010 Опубликовано 29 сентября, 2010 · Жалоба Про поставщиков было. 21. 21Ключевое поле для указания поставщиков и их номера один там почти необходимо, большее число желательно, 1- ROHS. 2- Поставщик. 3- Ревизия. 4- Комментарий к ревизии. Строка. Я так понял, альтиум заточен под SVN, но это не проблема, в этом случае нужно менять ревизию при каждом действии с компонентами. 5 Это очень полезная вещь. На основе этого можно будет потом сделать нормальную коллективную работу с базой. И еще выводить историю изменений компонента. 1. Это указано в зашифрованном виде в Part Number от производителя 2. Было. см выше 3. в таком виде--только рост параметров. А что делать если модифицировалось только УГО или Footprint? Достаточно один - дата модификации. и это касается только записи в БД. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
vitan 2 29 сентября, 2010 Опубликовано 29 сентября, 2010 · Жалоба Про поставщиков было. 21. 21Ключевое поле для указания поставщиков и их номера один там почти необходимо, большее число желательно, Угу. У меня так и есть. 1. Это указано в зашифрованном виде в Part Number от производителя Если бы существовал некий метод расшифровки (один на всех производителей в мире), тогда, конечно, это лишнее. 3. в таком виде--только рост параметров. А что делать если модифицировалось только УГО или Footprint? Достаточно один - дата модификации. и это касается только записи в БД. А в каком виде надо? Вопрос, что делать при изменении УГО или Footprint равносилен вопросу, что делать при изменении, скажем, поставщика. Ответ: да ничего не делать! Что именно Вам хотелось бы сделать, и для чего? Контролировать историю изменений УГО и футпринтов во времени и соотносить ее с историей компонентов? Какой в этом практический смысл? Я так понимаю, в Альтиуме компоненты УГО и футпринты хранятся никак не в базе. Так контролируйте их изменения стандартной системой контроля версий. А вот изменения в базе не получится так контролировать, придется изобретать некий механизм. Вот я его и предложил. Конечно, можно представить гипотетическую ситуацию, когда УГО постоянно меняется, и при этом хочется знать, что творилось в этот момент в базе с компонентом. Но лично мне за несколько лет этим заниматься так и не пришлось. Правда, я работаю не в Альтиуме. Это таки действительно нужно? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Uladzimir 80 29 сентября, 2010 Опубликовано 29 сентября, 2010 · Жалоба Если бы существовал некий метод расшифровки (один на всех производителей в мире), тогда, конечно, это лишнее. А в каком виде надо? Вопрос, что делать при изменении УГО или Footprint равносилен вопросу, что делать при изменении, скажем, поставщика. Ответ: да ничего не делать! Что именно Вам хотелось бы сделать, и для чего? Контролировать историю изменений УГО и футпринтов во времени и соотносить ее с историей компонентов? Какой в этом практический смысл? Я так понимаю, в Альтиуме компоненты УГО и футпринты хранятся никак не в базе. Так контролируйте их изменения стандартной системой контроля версий. А вот изменения в базе не получится так контролировать, придется изобретать некий механизм. Вот я его и предложил. Конечно, можно представить гипотетическую ситуацию, когда УГО постоянно меняется, и при этом хочется знать, что творилось в этот момент в базе с компонентом. Но лично мне за несколько лет этим заниматься так и не пришлось. Правда, я работаю не в Альтиуме. Это таки действительно нужно? Шифр на то и шифр, что разный. Никак Ну так и я о томже. Контролировать изменения УГО и футпринта не представляется возможным, так как это отдельные файлы Для контроля изменений в базе-- достаточно поля даты последней модификации. Не так там много полей, чтоб сравнить Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
vitan 2 29 сентября, 2010 Опубликовано 29 сентября, 2010 · Жалоба Шифр на то и шифр, что разный. Никак Поэтому ROHS нужен. :) Для контроля изменений в базе-- достаточно поля даты последней модификации. Не так там много полей, чтоб сравнить Понимаете, база - это не самоцель. Она должна быть сделана так, чтобы ей могли пользоваться все участники процесса. Начинается все, понятно, с разработки. Так вот, эта ревизия должна попадать в схему. Только так, глядя на схему, можно будет найти концы. Вы же собираетесь вести коллективную работу. Дата - просто неправильно. Дата и время - сойдет, но не информативно. Ревизия компонента - то, что нужно! Отлично понятно человеку и хорошо взаимодействует с системами контроля версий (если понадобится). Еще забыл парочку. - Признак разрешенности к применению. Это для военных. Там есть такие книжечки со списками. - Год редакции этой самой книжечки. Эти два очень сильно помогают генерить 1000-страничные обоснования применения элементной базы. Кто занимался, знает, как это утомительно. - Снятие с производства. Видел, что это предлагали, поддерживаю. У меня сделано датой. Если пусто, то считается, что не снято с производства. - Общие параметры компонентов. Пока таковыми считаю 4: Температуру хранения и рабочую. Минимум и максимум соответственно. Если база будет делаться с учетом деления компонентов на группы по параметрам с наследованием, как я писал выше, то тогда эти 4 можно будет засунуть на верхний уровень дерева, чтобы они оттуда отнаследовались на всех потомков. И еще по поводу УГО и футпринтов. Считаю правильным для компонентов делать не только ссылки на его УГО, но и на библиотеку, в которой УГО хранится. Я почему-то уверен, что везде, и в Альтиуме в т.ч., УГО не лежат в одной куче, а делятся на библиотеки. :) С футпринтами то же самое. Их надо делить. У меня это называется классами. Сделано на основе IPC-7351. Имея классы, можно быстро настроить редактор печатных плат для проведения хорошей авторасстановки. Ну и хранить их по папочкам с именами классов, естественно, под контролем версий. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Uladzimir 80 29 сентября, 2010 Опубликовано 29 сентября, 2010 · Жалоба Поэтому ROHS нужен. Нужен кому. Разработчику схемы --- нет. Он берет из базы то что нужно. Топологу-- нет. он может использовать только то, что идет из схемы, + выбор посадочного место по способу пайки Монтажнику-- да. Но это уже дополнительное. Не нужно в основные этот параметр в основные. Если и нужно-- то только ссылку на применимость ROHS. В общем как и цену компонента и т.п. То есть этот параметр не имеет прямого отношение к тем людям, кто работает в алтиуме и делает схему и плату. Еще забыл парочку. - Признак разрешенности к применению. Это для военных. Там есть такие книжечки со списками. - Год редакции этой самой книжечки. Эти два очень сильно помогают генерить 1000-страничные обоснования применения элементной базы. Кто занимался, знает, как это утомительно. - Снятие с производства. Видел, что это предлагали, поддерживаю. У меня сделано датой. Если пусто, то считается, что не снято с производства. - Общие параметры компонентов. Пока таковыми считаю 4: Температуру хранения и рабочую. Минимум и максимум соответственно. Если база будет делаться с учетом деления компонентов на группы по параметрам с наследованием, как я писал выше, то тогда эти 4 можно будет засунуть на верхний уровень дерева, чтобы они оттуда отнаследовались на всех потомков. Все это по той же причине. Как и сколько процентным бензином мыть плату, чтоб не смыть надписи. Вводит столько параметров, которые использует небольшое число пользователей-- похоронить на корню создание базы Нужно сделать главное-- а остальное ссылками. Кто хочет-- тот информацию ссылок и заполняет. Или подключает свою Так же как и данные у кого почем копили, когда придет, куда положили, сколько в запасе, что на утруску ушло .... Давайте с основными определимся. Пока и там споры жаркие будут Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
masterofnature 0 29 сентября, 2010 Опубликовано 29 сентября, 2010 · Жалоба Вводит столько параметров, которые использует небольшое число пользователей-- похоронить на корню создание базы Для этого можно подключить отдельную базу данных, которая будет связана с этой по ключевому полю. В этом случае запросами вы сможете сделать нужную вам выборку. Как я понимаю каждый может сделать на своем рабочем месте свою систему запросов? Может в таком случае удобнее будет раздробить БД на несколько для оптимизации доступа? Кто-то одними полями не пользуется, кто-то другими... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Uladzimir 80 29 сентября, 2010 Опубликовано 29 сентября, 2010 · Жалоба вот и я предлагал для этого пункты с 18 по 24. Можно добавить. Хотя... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jkrieger 0 29 сентября, 2010 Опубликовано 29 сентября, 2010 (изменено) · Жалоба Может в таком случае удобнее будет раздробить БД на несколько для оптимизации доступа? Кто-то одними полями не пользуется, кто-то другими... Идея здравая. Упирается в реализацию. Access поддерживает только абсолютные пути. А значит, если я изменю у себя ссылки на другие базы, то они изменятся у всех. С вариантом устанавливать базу в строго определенную папку на строго определенный диск я не готов. Запросы можно будет делать свои в базе-реплике. Так как запросы и формы не реплицируются, то каждый сможет нагородить в базе-реплике что угодно. Реплицироваться будут только нужные таблицы с компонентами. Так что свобода самовыражения останентся =) Пока привожу шаблон базы как я ее вижу. Это только заготовочка. В каждой таблице только обязательные поля. Еще будут поля параметров для каждой таблицы. Но то потом и неизвестно востребовано ли оно будет. Какие таблицы (категории компонентов) и поля следует добавить/удалить? UPD: я не создавал таблиц для п.п.18 - 24. И слабо представляю какими они должны быть acl.zip Изменено 29 сентября, 2010 пользователем Jack Krieger Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
vitan 2 29 сентября, 2010 Опубликовано 29 сентября, 2010 · Жалоба Вводит столько параметров, которые использует небольшое число пользователей-- похоронить на корню создание базы Нужно сделать главное-- а остальное ссылками. Кто хочет-- тот информацию ссылок и заполняет. Или подключает свою Про небольшое число пользователей. Я все хочу довести мысль, что база нужна не только рисовальщикам схем. Вы правильно говорите, что кто хочет, тот и заполняет. Только это входит в противоречие с понятием целостности данных. Надо объяснять, зачем она нужна? Все связанные поля при добавлении новой записи в БД должны быть заполнены. Можно принять, что по-умолчанию программа-клиент будет писать туда что-то типа N/A, но тогда кому такая база нужна? Проще говоря, это называется халявой. Про линки. Я уже говорил, что, к примеру, ROHS должен быть не строкой, а линком, как и все остальное, что может быть перечислено в отдельном справочнике (таблице по-простому). Пока мы не касались других объектов, для которых можно создать отдельные справочники, а обсуждаем основной справочник - справочник компонентов. Нужен кому. Разработчику схемы --- нет. Он берет из базы то что нужно. Неверно. Разработчик, имхо, должен быть подобен некоему гуру, который знает про девайс больше всех. Если он не будет знать о наличии бессвинцовых компонентов, то, он не сможет, к примеру, объяснить топологу, что нужно применять не обычный FR-4, а FR-4 Hi Tg (с повышенной температурой стеклования). Он же по каким-то соображениям выбирает "из базы то, что нужно". Так дайте ему полную информацию. Топологу-- нет. он может использовать только то, что идет из схемы, + выбор посадочного место по способу пайки Неверно. Продолжая мысль выше: если тополог выбирает неправильный текстолит, то он не может, к примеру, правильно рассчитать импедансы цепей. Последствия понятны? Стоит это секундной экономии при вводе компонента? Монтажнику-- да. Но это уже дополнительное. Не нужно в основные этот параметр в основные. Если и нужно-- то только ссылку на применимость ROHS. В общем как и цену компонента и т.п. То есть этот параметр не имеет прямого отношение к тем людям, кто работает в алтиуме и делает схему и плату. Понимаете, я предлагаю считать "основными" поля, которые являются общими для всех электронных компонентов для того, чтобы правильно организовать базу. Правильно, я считаю, - это одна таблица на все компоненты, ну я выше писал. Я не предлагаю выводить ROHS, поставщиков и прочую муть в схемотехнический редактор и загромождать там все лишними строками. В системах, с которыми я работал (ментор и кейденс) за непосредственный коннект с САПР отвечает доп. файлик настройки, в котором прописывается видимость полей, единицы измерения и проч. В альтиуме такое есть? Jack Krieger Вы не могли бы как-то выложить картинками или хотя бы в старом аксессе (2000). Не открывается. :( Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться