Вот.
Вынес отдельно. Предлагаю Первые 13 обязательны.
Последние нет
23 и 24. в основной базе не заполняются

Поля базы данных

1. 1. ID компонента (уникальное имя для всех таблиц базы)

2. 2. Название компонента (уникальное имя в таблице и ключевое поле )

3. 3. Порядковый номер в таблице

4. 4. Название схемного изображение

5. 5.Название Footprint

6. 6.Название Footprint для вертикальной установки

7. 7.Краткое описание компонента

8. 8.Изготовитель

9. 9.Номер компонента по изготовитель

10. 10Запись для перечня в столбце наименование

11. 11Запись для перечня в столбце примечание

12. 12Параметр для отображения на схеме

13. 13Дополнительный параметр, отображаемый на схеме

14. 14Параметр (функция компонента (логическая единица и т.п.)

15. 15Значение маркера на FootPrinte)

16. 16Ссылка на описание основного документа

17. 17Дата модификации записи

18. 18Ключевое поле на таблицу полей для симуляции

19. 19Ключевое поле для задания дополнительных параметров

20. 20Ключевое поле таблицы ссылок на вспомогательные документы

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

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

23. 23Ключевое поля для указания ссылки на склад

24. 24Ключевое поле таблицы для указания автора и прочей информации

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


Можно прояснить, зачем он нужен?


Здесь и далее должно быть не название, а ссылка на строку в отдельной таблице УГО и футпринтов.


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


А чем она отличается от п.9?


Интересная мысль, спасибо.


Можно прояснить?


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

На любителя. По мне, удобнее раздельно по основным группам: R, C, V, L, Q и т.д. Другие пассив в одну группу сваливают, актив - в другую... Я п.п. 16 и 20 не включаю в базу, так как завтра изменится web-ссылка... Разве-что хранить на винте все datasheet.

Я проходил и то и другое. Везде есть плюсы и минусы

В принципе не нужен. Только для сортировки в порядке создания

Нет это не строка. Это ссылка на файл с УГО и Footprint

Формально больше 2 я не знаю. Остальные по IPC 3 штуки и пользовательский можно не вводить, ограничясь только Normal
Просто названия у них должны совпадать, кроме последней буквы. Вся плата делается по одному стандарту, и в самой PCB замену этой буквы легко произвести скопом, для всего проекта.

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

Давно пользуюсь, и Вам желаю


22. С группами очень тяжело. не всегда все можно записать
14. Изображение компонета 2И, Логическое И и тп совпадают, бывает и с цоколевкой. Только этим симпволом
15. Люблю иногда писать на PCB? что на элементе отмаркировано. Иначе трудно понять, а то ли там запаяно
18 -19 - для любителей посимулировать.
Я практически не пользуюсь.
Но знаю кто делает это

Сразу несколько вопросов и уточнений:


Как это выполнить технически? Для отдной таблицы понятно, а для нескольких?


Откуда планируется брать этот параметр? Если он будет повторять ManufacturerNumber, то не вижу в нем смысла, если вручную, то нужно оговорить правила.

А вообще я предлагаю связывать компоненты по ключам Manufacturer + Manufacturer Number. Так имхо будет всегда однозначно и без лишней информации.


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


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

Думаю ключевым надо сделать порядковый номер в таблице

Мы проверили способы организации базы для альтиума и остановились на том варианте , когда есть централизованная база в локальной сети, доступная также по VPN из интернета. Клиент работы с этой базой самописный , заточен на склад , закупку , конструирование сборок , заведение ПКИ для альтиума и не только для него. Так вот в этой базе таблица компонентов одна, но для удобства работы в альтиуме она раскладывется "экспортом" на несколько таблиц по классам компонента и ложится на локальный компьютер альтиум-работника. Тем самым достигается приличная производительность работы библиотеки под альтиумом. Все иные варианты при большом количестве альтиум-компонентов (более 2000шт у нас) даже в локалке показывают жуткие тормоза. Альтиум черпает инфу из базы мелкими порциями, так что все нелокальные варианты базы у нас не прошли.
Надеюсь что эта инфа как-то поможет, возможно.

Добавить первую букву таблицы. Может 2


В принципе лишнее, но не всегда известны Manufacturer + Manufacturer Number
К тому же в Manufacturer Number присутствует и маркировка в чем поставляется (в тубах лентах). А это иногда лишнее


Это уже другая сортировка. Но я писал. параметр не существенный


Не. Такой информации в верхних полях может и не быть



Таблицу можно и одну.
Любителям раздельных-- можно организовать по запросам.
Или наоборот. Раздельные -- о общую по запросам

Информации по тормозам ожидаема. Только по этой причине я за раздельные таблицы


В принципе может быть несколько ключевых полей

Я тоже проходил и то, и другое. Интересно, почему мы остановились на разном?
Я считаю, что таблицы в базе должны отражать описание объектов реального мира. В моем случае основной объект - это компоненты, для них есть своя таблица. Для футпринтов - своя, ну и т.п. Одним из объектов является тип компонента. Имея это легко делается группировка компонентов по разным признакам, например, по типам. А имея хорошо управляемые и хорошо описанные группы, можно легко назначать им специфические свойства. У меня имеется целое дерево групп с иерархией. К примеру, на верхнем уровне стоят конденсаторы. От них наследуются конденсаторы керамические, рядом - танталовые. При этом легко назначаются групповые параметры. У всех конденсаторов общий параметр - емкость, он наследуется и на керамику, и на тантал. А на нижнем уровне можно задать свои параметры.
Все это деление при этом никак не затрагивает общую таблицу компонентов, они в ней лежат "хаотически". Зато можно добавлять любые способы группировки. В данный момент думаю, как бы создать группировку "актив-пассив-...", как на сайте чип и дипа.
А плюсы деления на таблицы я вижу пока только в быстроте создания.


+1. Только у меня раскладывается не экспортом, а запросами.


А что еще?


Идея здравая. Я в интернете в нескольких местах видел высказывания людей, занимающихся подобными проблемами. Все они говорят, что ни разу не видели, чтобы эта комбинация где-то повторилась. Поначалу я тоже именно так и сделал. НО! Тут как всегда оказалось, что думать надо было своей головой. В один момент мне попались очень хитрые компоненты, это были обычные разъемы CompactPCI. В этой системе есть модули, которые можно устанавливать в кросс-плату с двух сторон навстречу друг другу. Разъемы используются одни и те же. Только при этом нумерация выводов на плате у них зеркальная. В результате сделать по коду заказа не получилось, т.к. хотелось иметь одну строку в таблице, отвечающую за правильный компонент. И ключом для компонента нужно делать некий свой, внутренний, парт намбер. В пользу этого есть еще один маленький довод: в оригинальных партнамберах производителей иногда встречаются символы типа скобочек, пробелов, запятых и т.п., от которых у САПР сносит крышу.
Короче, у меня компоненты отличаются по искусственному коду, а оригинальный лежит рядом и используется для генерации документации.

Не думаю, что сильно на разном.

+ Запрос рулит

Вот и я попадал, когда компонент есть, а комбинации из этих двух параметров нет
К тому же есть топологические объекты, у которых ни завода ни тем более номера

Краткое описание и основные
Надпись Резистор-- и есть описание

Угу. И это еще один довод в копилку про одну таблицу для компонентов. Такие объекты будет проще классифицировать. Вот их-то надо в отдельную таблицу.


Ну, это не проблема. Перед началом группы резисторов пишется слово "Резисторы". А сама запись берется прямо из поля кода заказа, без синтезирования ее из параметров.

"экспорт" в клиенте - это выполнение запросов. я неясно выразился. Но таблицы на локальном компе лучше иметь всё же в виде таблиц а не запросов. Так быстрее отрываются свойства компонентов на схеме. Про запросы я писал еще в http://electronix.ru/forum/index.php?showt...mp;#entry693995 но с тех пор было выявлено что такие варианты запросов всё же неоптимальны.

Про отдельную таблицу про них не допер
Хотя они у меня и так в таблице РАЗНОЕ лежали

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

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

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

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


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

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

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


В аксесе указывается запрет повторов. Оно не даст. По крайней мере в таблице
Но если ключевое поле формируется из двух или более параметров-- клинч.
Каждый параметр в отдельности может иметь совпадения, но результат объединения -- нет.
Как это сделать а Access не знаю. Я не большой специалист

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

ключевое поле из нескольких полей делается так:
редактируете "таблица в режиме конструктора" ;
выделяете насколько строк где содержатся интересующие Вас поля при нажатой клавише CTRL;
не отпуская CTRL правой клавишей мыши входите в контекстное меню и выбираете в нем "ключевое поле".

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

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

Что касаемо полей в основной таблице компонентов, то могу посоветовать добавить следующие.
- ROHS. Лучше не просто "да-нет", а выбирать из справочника. Их там может быть несколько вариантов, если почитать. Это нужно для быстрого понимания, как паять.
- Поставщик. (вроде, не было). Ссылка на постащика в справочнике поставщиков. Для генерации ВП.
- Ревизия. Лично у меня принята система, аналогичная CVS, где ревизии растут отдельно для каждого компонента. При очередном изменении юзеру выводится предупреждение, что ревизия будет инкрементирована, и выводится окно, в которое он записывает текст. Текст попадает в следующее поле (после проверки на пустую строку).
- Комментарий к ревизии. Строка.

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

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

В альтиуме следует применять для связи строку:
[Manufacturer] = '{Manufacturer}' AND [Manufacturer Number] = '{Manufacturer Number}'

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

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

Про поставщиков было.
21. 21Ключевое поле для указания поставщиков и их номера
один там почти необходимо, большее число желательно,


1. Это указано в зашифрованном виде в Part Number от производителя
2. Было. см выше
3. в таком виде--только рост параметров. А что делать если модифицировалось только УГО или Footprint?
Достаточно один - дата модификации. и это касается только записи в БД.

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


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


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

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

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


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

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

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

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

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

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

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

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

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

Как я понимаю каждый может сделать на своем рабочем месте свою систему запросов?
Может в таком случае удобнее будет раздробить БД на несколько для оптимизации доступа?
Кто-то одними полями не пользуется, кто-то другими...

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

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

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

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

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

Нажмите для просмотра прикрепленного файла

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


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


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


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

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

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


Ладно. кусаю ногти. Имел ввиду схемотехника. Разработчик-- это бог

Ну текстолит это материал, и в базу не попадет.
Вообще выбор материала, стека слоев и расчет импеданса-- это не только тополог --но и завод. Тополог не знаетЮ на сколько сожмется препрег на заводе. А на заводе знают. Не будем крайности притягивать за уши.

Гм. Надо смотреть тогда глубже.
Вы предлагаете создать всеобщую базу. В ней схемотехническая-- только часть.
Поймите. в алтиуме если из базы параметры не введутся на схему-- в отчеты информации достать можно но сложно, и никто делать не будет.
С точки зрения схемотехника. Сори Разработчика-- база ничего не дает. Мне в первую очередь нужно изучить PDF на компонент, прежде чем я поставлю его на схему. а не краткую информацию есть у него ROHS, или он снят с производства.
Если снят с производства -- не чего его в базу заносить. А если уж там есть-- помечать или удалять сразу.





Для начала не плохо. Но желательно форму сделать. сейчас может и рано но необходимо будет. Тамже нужны и подсказки, что за поле и в каком формате ее заводить.
Ключевые поля класс работают, это радует.
Вот моя старая база. посмотрите. Там форма совмещенная с таблицей.
Может навеет на что

Не надо. Они сами должны к этому прийти. А Вы покажете пример. Иначе ничего не выйдет.


Вы думаете, завод Вам обеспечит сладкую жизнь? Вы пробовали заказать расчет импедансов, скажем, в Резоните?
Я бы не стал называть этот пример крайностями, да еще притянутыми за уши. Это жизнь.
Если все еще сомневаетесь, вот Вам еще пример. Очень многие компоненты, не соответствующие ROHS, привезти в Россия у Вас не получится из-за экспортной политики. А еще, компоненты ROHS нельзя применять в изделиях ВТ. А еще... Продолжать? Вы все это будете мануально отслеживать? Для серьезных разработок такая база не годится, она будет похожа на демо какое-то.


А Вы хотите жить в инкубаторе и ни с кем не разговаривать? Вы схему вообще зачем рисуете? Если только для себя, то можно и не рисовать, не правда ли?
К общей базе надо стремиться, не пытаться сделать сразу, а именно стремиться.


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


Ого! А что ж Вы тогда ее затеяли? Вы действительно будете каждый раз изучать PDF на резистор, когда Вам нужно будет поставить новый номинал? Или Выберете из базы, не задумываясь, и зная, что там все уже проверено?


Ну-ну. А с заделом, к примеру, что делать?


А где?

Версия для Access 2000

UPD: По поводу форм. Если честно, у меня не получилось нормально сделать форму.

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

Нельзя вообще, если в Европу али Америку хочется лезть. Уж более 5 лет с контрагенты запрещают использование вредных компонентов.

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

Не утрируйте. Во перевых на прецизионные читаю, во вторых даташит один не только на все номиналы, а порой и на группу футпринтов

Забыл.
Вечером



Это легко. Зато удобно
Вечером выложу базу, там есть такая форма

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


Если можно, в старом аксессе.

Я нет. Не мне ее создавать. Мне своих хватает
Вот отпугнуть юзеров--- Это 100% , А база задумывается для них, или для совместного пользования
Чтоб узнать путь правильный, или нет, по нем надо хотя бы идти, а не разговаривать как идти.
Переделать сложно. Да. Вот поэтому я за путь подключения по ссылкам других. Тогда что то новое подключится оптом потом.
Справочник всегда один. но может быть многотомным. Полную Большую советскую энциклопедию как то не принято в одном томе издавать. Автопогрузчик нужен.
На счет других справочников. Что мы еще забыли-- Карты настройки?

Что-то я Вас перестаю понимать. Я ходил и пытаюсь Вам сказать, куда ходить не надо.

Так закройте топик! Действительно, чего зря болтать, дело надо делать!


Еще раз: под справочниками в мире БД принято называть таблицы, хранящие в себе значения полей, описывающие один и тот же объект. Справочники создаются для сущностей реального мира и абстрактных объектов. Я предложил вначале обсудить поля, характерные для описания компонентов. Мы обсудили отдельные поля, однако в процессе обсуждения Вы прямо так ни разу и не ответили, согласны ли Вы с общей концепцией.
Посему два вопроса.
1. Вы согласны с таким способом хранения информации, или предпочитаете иметь разные таблицы для резисторов, конденсаторов и т.п.?
2. Если согласны, то готовы ли Вы обсудить, какие другие объекты, кроме компонентов, должны быть в базе, т.е. какие еще нужны справочники?

Нет. пока я вижу, что вы пишете куда надо идти. А это не одно и тоже

Топик я открывал не для себя. Меня мои устраивают, а когда начинают устраивать-- я их переделываю, дополняю, ...
Шла речь как лучше, проще и удобней их строить

Я не только предложил, но и привел их список.

В основном это касалось Rosh.
Я был на мнении, что данная информации уже есть в названии компонента.
В целом как и цвет клеммника, который тоже важен!!! И таких параметров можно найти тысячу и еще один.
Вот эти параметры и предложил вводить через линки, или вообще в текстовом виде как краткое описание компонента.
Вы же стоите но позиции-- каждому свойству- свой параметр, или я не правильно понял?
Если это концепция-- я не согласен, и готов дискутировать

Не внимательно читали. Я уже писал выше. Можно и так итак.
Либо Общую получать запросами, либо частные формировать запросами.
Это не принципиально, если не касаться размеров для скачивания, синхронизации и т.п.

На данном этапе - никакие. Так как базы вообще ни, нет даже полей для ввода параметров

Но меня это тоже интересует. У меня есть таблицы поставщиков, производителей, посредников, применяемости....
Но на этом этапе нет.

Еще раз повторю.
Я давно работаю с базой и меня оно более менее устраивает
Здесь речь пошла у совместной базе и выработке ее структуры.
Давайте начнем со скелета, и хотя бы увидим там те параметры, о которых спора нет

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


Это половина концепции. Пойдем Вашим же методом: если взять название компонента, то по нему можно вычислить _абсолютно все_ его параметры, не так ли? Зачем же тогда база? Зачем столбцы с футпринтом? Ведь он же зашифрован в названии!
Очевидно, в базе должна содержаться некая информация, доступная без "дешифрации". И о необходимости этой информации, мы, собственно, и разговариваем. Так вот, чертов ROHS я лично считаю необходимым по причинам, изложенным выше.


Господи, да читал я! Вы свое мнение можете выразить, наконец, а не перечислять возможные варианты? Я считаю, что это очень принципиально, почему уже тоже написал.


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


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

Это не то, что написано в PDF, а то как имя реального Footprint, который автоматически подключается при передачи изменений из схемы в PCB

Ну так давайте. Насколько я понял у Вас тоже есть?
Вот тут я категорически против.
Хотя раньше был на этой позиции

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


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


И? Сначала уж скажите почему, а то я все вещаю, а меня начинают упрекать, что я, мол, начинаю всех жизни учить...

Естественно. В PDF указан тип корпуса, а не Footprint
Последний учитывает и способ монтажа.
Это разные вещи в принципе.
В моей базе кстати есть параметр "тип корпуса", только для того, чтобы проконтролировать, а правильный ли Footprint подключен.
Правильно вы заметили, что та же ситуация что и "в т.ч. пресловутым ROHS."
Но я постоянно говорю, что ограничить обязательными параметрами теми, Без которых вообще компонент не получается как единое целое, и добавить те, которые в принципе дают ссылки, откуда можно получить дополнительные параметры, если они есть, введены и не пустые.
Замечу. Я ведь не настаиваю на параметре "тип корпуса".
Хотя желал бы иметь обозначение этого корпуса в разных стандартах.
Вы же знаете, что в разных стандартах один и тот же корпус имеет разное обозначение?

Это не важно. Достаточно скреен название столбцов, строк., таблиц...

Да я уж неоднократно писал
Все компоненты в кучу-- это уже есть в родных библиотеках.
Кто пользуется знает как....
1 При этом при правке изменения нужно копировать всю здоровую библиотеку.
2. Если она изменилась-- неизвестно какие компоненты подверглись изменению
3. Если кто-то вносил изменения в один компонент библиотеки, где гарантия, что случайным образом не внесены изменения в другие компоненты
4...

1. С одним справочник на все компоненты не согласен. Мне кажется будет лучше разделить их на каттегории - транзисторы, резисторы, микросхемы, выключатели и т.п. Зачем? В каждой таблице кроме основных полей будут поля, относящиеся к конкретной категории, например, тип транзистора (NPN, PNP, MOSFET-N....). Это пригодится для сортировки и группировки компонентов уже в Альтиуме. Конечно не все параметры будут записываться, а какие-то самые важные.
2. Если вы имеете ввиду что то вроде этих топологических элементов, то мне кажется это можно будет добавить позже, когда будет более менее отлажено остальное.

Теперь вопрос знатокам Access. Можно ли связать две таблицы в разных файлах по двум ключевым полям? А в одном файле?

В разных файлах не знаю, в одном просто
в меню Pabota c бфзами данных/ схема данных.
Там понятно

я не знаток , но попробую ответить.
на главном окне базы в Access по контекстному меню щелкаете "связь с таблицами" . Предложит выбрать другую mdb базу и таблицы из неё по вашему выбору.
Выбрали - эти таблицы теперь появились в исходной базе (выделяются стрелочками слева от значков обычных таблиц)

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

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

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

А какие связи Надежны и раз и навсегда?

Я тоже давно хочу ввести это. Но пока откладываю.


Ээээ... Я че-то не догоняю. Вы таки за или против деления УГО на библиотеки? Вначале - категорически против, теперь, вроде бы - за...


Видите ли, я об этом же написал выше. Чтоб не быть голословным, в аттаче скрин из клиента. На нем видно, что разным компонентам назначаются разные свойства _в зависимости от категории_. При этом все компоненты физически хранятся в одной таблице вне зависимости от категорий.


Я имею ввиду не это, а справочники других сущностей. И уже начал обсуждение способа хранения сущности "УГО" с Владимиром. Следующим справочником (после окончания обсуждения этого) предлагаю обсудить справочник футпринтов.

vitan, простите, не дочитал.

Сразу выскажу одно "ограничение" так сказать. Для разрабатываемой библиотеки никакого клиента не будет. Ну кроме MS Access для ввода новых компонентов =) Во всяком случае я надеюсь, что можно обойтись только им.

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

Таблица футпринтов. Да, нужна. Так как при создании компонента хочется видеть только тип корпуса, который можно будет выбрать из списка. А этому типу корпуса в таблице футпринтов будут соответствовать 4-5 посадочных мест, описание и т.п.

Таблица производителей. Опять же только для удобства выбора при добавлении ИМХО.

Таблица симуляции. Мне очень хочется чтобы была.

Что там еще было?

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

главным преимуществом хранения инфы в базе является контроль целостности.

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

Согласен. Клиентская часть должна быть на свой вкус.


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


Правильно. Но еще раз хочу напомнить, что футпринты тоже надо группировать. Причины - выше.


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


Я пока до этого не дошел, но тоже хочу. Я попозже еще Вас помучаю на эту тему?


В общем, согласен. Но мне одно непонятно, как Вы соираетесь обесепчивать целостность данных, если ссылки будут вести вникуда?

Да, по поводу таблицы компонентов. Чуть не забыл самое интересное - поле "проверено". У меня если там True, то только тогда этот компонент виден в запросе, который исходит от САПР. Т.е. непроверенные компоненты просто физически нельзя поставить на схему. Процесс проверки сделан средствами BPM/Workflow. Работает неплохо, советую. Тут просто были упоминания о некоем "библиотекаре". Думаю, его никогда не появится. А вот организовать коллективную проверку с помощью чего-то подобного, думаю это - самое то.