[Uladzimir 80]

Владимир, что такое топологический компонент?

 

Кстати компоненты, которые вы привели в пример случаев с отсутствием Manufacturer или ManufacturerNumber я даже не знаю в какую из групп (таблиц) отнести. А значит для них будет отдельная группа, где можно будет сделать исключение из общих правил.

 

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

 

Примеры с отсутствием-- пожалуйста, резисторы, конденсаторы советского производства, на которые указывается только ТУ

 

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

Как сделано в Альтиуме мне интересно только теоретически. Я его ни разу в глаза не видел. Но пытаюсь обобщить, так сказать...

 

 

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

В аксесе указывается запрет повторов. Оно не даст. По крайней мере в таблице

Но если ключевое поле формируется из двух или более параметров-- клинч.

Каждый параметр в отдельности может иметь совпадения, но результат объединения -- нет.

Как это сделать а Access не знаю. Я не большой специалист

 

Про топологические-- принято в отдельные. На них ни перечня ни покупных делать не надо

[тау 31]

Но если ключевое поле формируется из двух или более параметров-- клинч.

Каждый параметр в отдельности может иметь совпадения, но результат объединения -- нет.

Как это сделать а Access не знаю. Я не большой специалист

ключевое поле из нескольких полей делается так:

редактируете "таблица в режиме конструктора" ;

выделяете насколько строк где содержатся интересующие Вас поля при нажатой клавише CTRL;

не отпуская CTRL правой клавишей мыши входите в контекстное меню и выбираете в нем "ключевое поле".

 

Всё- эти поля станут общим ключом, не допускающим совокупных совпадений по всем ключевым полям.

Будет ли съедобна такая таблица для альтиума - не знаю. Он любит вроде бы одно ключевое поле.

 

[Uladzimir 80]

Спасибо попробую

В алтиуме тоже можно задавать по куче параметров. Там ниже окно с построителем выражений

[vitan 2]

Что касаемо полей в основной таблице компонентов, то могу посоветовать добавить следующие.

- ROHS. Лучше не просто "да-нет", а выбирать из справочника. Их там может быть несколько вариантов, если почитать. Это нужно для быстрого понимания, как паять.

- Поставщик. (вроде, не было). Ссылка на постащика в справочнике поставщиков. Для генерации ВП.

- Ревизия. Лично у меня принята система, аналогичная CVS, где ревизии растут отдельно для каждого компонента. При очередном изменении юзеру выводится предупреждение, что ревизия будет инкрементирована, и выводится окно, в которое он записывает текст. Текст попадает в следующее поле (после проверки на пустую строку).

- Комментарий к ревизии. Строка.

 

Я так понял, альтиум заточен под SVN, но это не проблема, в этом случае нужно менять ревизию при каждом действии с компонентами.

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

 

[jkrieger 0]

тау, большое спасибо! Я чувствовал, что так возможно сделать, но не знал как. Теперь проблемы с идентификацией компонента и репликацией баз быть не должно.

 

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

[Manufacturer] = '{Manufacturer}' AND [Manufacturer Number] = '{Manufacturer Number}'

 

vitan, так как это база не для склада, то мы не вводим поля вроде Поставщик или Цена. Ну а строить систему контроля версий внутри БД думаю тоже будет накладно. Это немного не то, что предлагает Altium для SVN.

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

[vitan 2]

vitan, так как это база не для склада, то мы не вводим поля вроде Поставщик или Цена. Ну а строить систему контроля версий внутри БД думаю тоже будет накладно. Это немного не то, что предлагает Altium для SVN.

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

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

[Uladzimir 80]

Про поставщиков было.

21. 21Ключевое поле для указания поставщиков и их номера

один там почти необходимо, большее число желательно,

 

1- ROHS.

2- Поставщик.

3- Ревизия.

4- Комментарий к ревизии. Строка.

 

Я так понял, альтиум заточен под SVN, но это не проблема, в этом случае нужно менять ревизию при каждом действии с компонентами.

5 Это очень полезная вещь. На основе этого можно будет потом сделать нормальную коллективную работу с базой. И еще выводить историю изменений компонента.

1. Это указано в зашифрованном виде в Part Number от производителя

2. Было. см выше

3. в таком виде--только рост параметров. А что делать если модифицировалось только УГО или Footprint?

Достаточно один - дата модификации. и это касается только записи в БД.

[vitan 2]

Про поставщиков было.

21. 21Ключевое поле для указания поставщиков и их номера

один там почти необходимо, большее число желательно,

Угу. У меня так и есть.

 

1. Это указано в зашифрованном виде в Part Number от производителя

Если бы существовал некий метод расшифровки (один на всех производителей в мире), тогда, конечно, это лишнее.

 

3. в таком виде--только рост параметров. А что делать если модифицировалось только УГО или Footprint?

Достаточно один - дата модификации. и это касается только записи в БД.

А в каком виде надо?

Вопрос, что делать при изменении УГО или Footprint равносилен вопросу, что делать при изменении, скажем, поставщика. Ответ: да ничего не делать! Что именно Вам хотелось бы сделать, и для чего? Контролировать историю изменений УГО и футпринтов во времени и соотносить ее с историей компонентов? Какой в этом практический смысл? Я так понимаю, в Альтиуме компоненты УГО и футпринты хранятся никак не в базе. Так контролируйте их изменения стандартной системой контроля версий. А вот изменения в базе не получится так контролировать, придется изобретать некий механизм. Вот я его и предложил.

Конечно, можно представить гипотетическую ситуацию, когда УГО постоянно меняется, и при этом хочется знать, что творилось в этот момент в базе с компонентом. Но лично мне за несколько лет этим заниматься так и не пришлось. Правда, я работаю не в Альтиуме. Это таки действительно нужно?

[Uladzimir 80]

Если бы существовал некий метод расшифровки (один на всех производителей в мире), тогда, конечно, это лишнее.

 

 

А в каком виде надо?

Вопрос, что делать при изменении УГО или Footprint равносилен вопросу, что делать при изменении, скажем, поставщика. Ответ: да ничего не делать! Что именно Вам хотелось бы сделать, и для чего? Контролировать историю изменений УГО и футпринтов во времени и соотносить ее с историей компонентов? Какой в этом практический смысл? Я так понимаю, в Альтиуме компоненты УГО и футпринты хранятся никак не в базе. Так контролируйте их изменения стандартной системой контроля версий. А вот изменения в базе не получится так контролировать, придется изобретать некий механизм. Вот я его и предложил.

Конечно, можно представить гипотетическую ситуацию, когда УГО постоянно меняется, и при этом хочется знать, что творилось в этот момент в базе с компонентом. Но лично мне за несколько лет этим заниматься так и не пришлось. Правда, я работаю не в Альтиуме. Это таки действительно нужно?

Шифр на то и шифр, что разный. Никак

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

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

[vitan 2]

Шифр на то и шифр, что разный. Никак

Поэтому ROHS нужен. :)

 

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

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

 

Еще забыл парочку.

- Признак разрешенности к применению. Это для военных. Там есть такие книжечки со списками.

- Год редакции этой самой книжечки.

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

- Снятие с производства. Видел, что это предлагали, поддерживаю. У меня сделано датой. Если пусто, то считается, что не снято с производства.

- Общие параметры компонентов. Пока таковыми считаю 4: Температуру хранения и рабочую. Минимум и максимум соответственно. Если база будет делаться с учетом деления компонентов на группы по параметрам с наследованием, как я писал выше, то тогда эти 4 можно будет засунуть на верхний уровень дерева, чтобы они оттуда отнаследовались на всех потомков.

 

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

С футпринтами то же самое. Их надо делить. У меня это называется классами. Сделано на основе IPC-7351. Имея классы, можно быстро настроить редактор печатных плат для проведения хорошей авторасстановки. Ну и хранить их по папочкам с именами классов, естественно, под контролем версий.

[Uladzimir 80]

Поэтому ROHS нужен.

Нужен кому. Разработчику схемы --- нет. Он берет из базы то что нужно.

Топологу-- нет. он может использовать только то, что идет из схемы, + выбор посадочного место по способу пайки

Монтажнику-- да. Но это уже дополнительное. Не нужно в основные этот параметр в основные.

Если и нужно-- то только ссылку на применимость ROHS. В общем как и цену компонента и т.п.

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

Еще забыл парочку.

- Признак разрешенности к применению. Это для военных. Там есть такие книжечки со списками.

- Год редакции этой самой книжечки.

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

- Снятие с производства. Видел, что это предлагали, поддерживаю. У меня сделано датой. Если пусто, то считается, что не снято с производства.

- Общие параметры компонентов. Пока таковыми считаю 4: Температуру хранения и рабочую. Минимум и максимум соответственно. Если база будет делаться с учетом деления компонентов на группы по параметрам с наследованием, как я писал выше, то тогда эти 4 можно будет засунуть на верхний уровень дерева, чтобы они оттуда отнаследовались на всех потомков.

Все это по той же причине.

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

 

Вводит столько параметров, которые использует небольшое число пользователей-- похоронить на корню создание базы

Нужно сделать главное-- а остальное ссылками. Кто хочет-- тот информацию ссылок и заполняет. Или подключает свою

 

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

 

Давайте с основными определимся.

Пока и там споры жаркие будут

 

[masterofnature 0]

Вводит столько параметров, которые использует небольшое число пользователей-- похоронить на корню создание базы

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

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

 

Как я понимаю каждый может сделать на своем рабочем месте свою систему запросов?

Может в таком случае удобнее будет раздробить БД на несколько для оптимизации доступа?

Кто-то одними полями не пользуется, кто-то другими...

 

[Uladzimir 80]

вот и я предлагал для этого пункты с 18 по 24.

Можно добавить. Хотя...

[jkrieger 0]

Может в таком случае удобнее будет раздробить БД на несколько для оптимизации доступа?

Кто-то одними полями не пользуется, кто-то другими...

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

 

Запросы можно будет делать свои в базе-реплике. Так как запросы и формы не реплицируются, то каждый сможет нагородить в базе-реплике что угодно. Реплицироваться будут только нужные таблицы с компонентами. Так что свобода самовыражения останентся =)

 

Пока привожу шаблон базы как я ее вижу. Это только заготовочка. В каждой таблице только обязательные поля. Еще будут поля параметров для каждой таблицы. Но то потом и неизвестно востребовано ли оно будет.

Какие таблицы (категории компонентов) и поля следует добавить/удалить?

 

UPD: я не создавал таблиц для п.п.18 - 24. И слабо представляю какими они должны быть

 

acl.zip

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

[vitan 2]

Вводит столько параметров, которые использует небольшое число пользователей-- похоронить на корню создание базы

Нужно сделать главное-- а остальное ссылками. Кто хочет-- тот информацию ссылок и заполняет. Или подключает свою

Про небольшое число пользователей.

Я все хочу довести мысль, что база нужна не только рисовальщикам схем. Вы правильно говорите, что кто хочет, тот и заполняет. Только это входит в противоречие с понятием целостности данных. Надо объяснять, зачем она нужна? Все связанные поля при добавлении новой записи в БД должны быть заполнены. Можно принять, что по-умолчанию программа-клиент будет писать туда что-то типа N/A, но тогда кому такая база нужна? Проще говоря, это называется халявой.

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

 

Нужен кому. Разработчику схемы --- нет. Он берет из базы то что нужно.

Неверно. Разработчик, имхо, должен быть подобен некоему гуру, который знает про девайс больше всех. Если он не будет знать о наличии бессвинцовых компонентов, то, он не сможет, к примеру, объяснить топологу, что нужно применять не обычный FR-4, а FR-4 Hi Tg (с повышенной температурой стеклования).

Он же по каким-то соображениям выбирает "из базы то, что нужно". Так дайте ему полную информацию.

 

Топологу-- нет. он может использовать только то, что идет из схемы, + выбор посадочного место по способу пайки

Неверно. Продолжая мысль выше: если тополог выбирает неправильный текстолит, то он не может, к примеру, правильно рассчитать импедансы цепей. Последствия понятны? Стоит это секундной экономии при вводе компонента?

 

Монтажнику-- да. Но это уже дополнительное. Не нужно в основные этот параметр в основные.

Если и нужно-- то только ссылку на применимость ROHS. В общем как и цену компонента и т.п.

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

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

 

Jack Krieger

Вы не могли бы как-то выложить картинками или хотя бы в старом аксессе (2000). Не открывается. :(