[Uladzimir 73]

Вот.

Вынес отдельно. Предлагаю Первые 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Ключевое поле таблицы для указания автора и прочей информации

 

 

[vitan 2]

Это, очевидно, в продолжение вот этого?

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

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

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

 

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

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

 

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

 

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

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

 

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

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

 

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

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

 

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

 

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

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

 

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

 

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

 

 

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

 

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

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

 

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

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

 

 

[dvf 1]

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

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

[Uladzimir 73]

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

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

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

 

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

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

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

 

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

 

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

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

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

 

Очевидно, имеется ввиду некий альтернативный футпринт?

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

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

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

 

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

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

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

 

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

 

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

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

Цитата(Владимир @ Sep 28 2010, 22:41) *

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

 

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

 

 

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

 

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

 

 

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

 

22. С группами очень тяжело. не всегда все можно записать

14. Изображение компонета 2И, Логическое И и тп совпадают, бывает и с цоколевкой. Только этим симпволом

15. Люблю иногда писать на PCB? что на элементе отмаркировано. Иначе трудно понять, а то ли там запаяно

18 -19 - для любителей посимулировать.

Я практически не пользуюсь.

Но знаю кто делает это

 

 

 

[jkrieger 0]

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

 

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

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

 

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

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

 

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

 

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

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

 

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

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

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

[masterofnature 0]

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

[тау 31]

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

Надеюсь что эта инфа как-то поможет, возможно.

[Uladzimir 73]

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

 

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

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

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

 

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

 

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

В принципе лишнее, но не всегда известны Manufacturer + Manufacturer Number

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

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

 

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

 

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

 

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

 

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

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

 

 

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

Надеюсь что эта инфа как-то поможет, возможно.

Таблицу можно и одну.

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

Или наоборот. Раздельные -- о общую по запросам

 

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

 

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

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

[vitan 2]

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

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

Я тоже проходил и то, и другое. Интересно, почему мы остановились на разном?

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

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

А плюсы деления на таблицы я вижу пока только в быстроте создания.

 

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

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

 

В граве наименование пишется не только п9.

А что еще?

 

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

 

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

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

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

[Uladzimir 73]

Я тоже проходил и то, и другое. Интересно, почему мы остановились на разном?

 

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

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

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

Идея здравая....

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

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

А что еще?

Краткое описание и основные

Надпись Резистор-- и есть описание

[vitan 2]

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

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

 

Краткое описание и основные

Надпись Резистор-- и есть описание

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

[тау 31]

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

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

[Uladzimir 73]

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

 

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

Про отдельную таблицу про них не допер :(

Хотя они у меня и так в таблице РАЗНОЕ лежали

[jkrieger 0]

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

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

 

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

 

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

 

[vitan 2]

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

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

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

 

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

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