Вот.
Вынес отдельно. Предлагаю Первые 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).

Сообщение отредактировал Jack Krieger - Sep 29 2010, 08:21

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

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

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


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


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


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



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

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


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

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


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


А что еще?


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

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

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

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

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

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


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

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

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

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

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

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

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


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