База данных CIS и полиморфизм компонентов, или как структурировать CIS Опции

[Hoodwin]

Можно ли организовать базу данных CIS таким образом, чтобы основной набор свойств компонентов хранился в одной большой таблице, а остальные данные хранились в дополнительных, более мелких таблицах, ссылающихся на базовую?
Ну, например, берем bench.mdb и видим, что таблица резисторов и конденсаторов по набору свойств почти совпадают. Строго говоря, все свойства, необходимые для CIS вообще совпадают, а некоторые физические свойства могут отличаться: у резисторов указывается мощность, а у конденсаторов - напряжение.
Мне такая организация не очень нравится. Хотелось бы иметь возможность в будущем вносить изменения в структуру базы данных. С большой вероятностью таковые изменения коснутся базового объекта, а не какого-то отдельного класса компонентов. Например, вот был раньше Layout и просто Footrint, а потом добавили Аллегро, и надо теперь уже в базе иметь два свойства - Layout PCB Footrint и Allegro PCB Footrint. при нынешней организации придется в каждой таблице прописывать новые поля, а так можно только в одной таблице прописать.

Я правильно думаю, что можно создать таблицу типа basic_cis, а потом во вкладке relational database прописать ее в качестве связанной таблицы для всех типов компонентов? И тогда в качестве связующего поля останется только part number? Или CIS использует для работы основную базу, а связанные только для просмотра свойств, и вся идея рушится?

[Hoodwin]

Вот еще какие вопросы по работе с CIS средствами SQL:
1. Правильно ли я понимаю, что столбец БД, указанный конфигуратору как Part_Number (см. рисунок) - это уникальный номер компонента в базе CIS. То есть это не Part Number производителя, потому что теоретически два разных производителя могут выдать одинаковый артикул, в особенности те, кто нумерацию ведет только строками чисел. Смысл этого номера в том, чтобы CIS однозначно мог найти компонент в базе при операциях обновления свойств и т.п. Я поначалу сделал его обычным номером производителя, но сейчас вот думаю перевести его на UUID, который SQL сервер умеет генерировать.
2. Почему перестал работать preview футпринта в CIS Explorer? Вроде бы раньше работал для smdres. Сейчас не работает. Причем пути к библиотекам прописаны, если навести курсор на это поле, то пишет правильный путь к .dra, но символ не показывает.
3. Можно ли убрать из списка таблиц все системные таблицы SQL? Ну или более точно, можно ли явно показать вполне конкретные таблицы CIS? У меня сейчас для простоты всего две (View) созданы, а при этом оно из базы высасывает конфиг от 357 таблиц, в итоге этот сонфиг в XML кушает 2.4 МБ и долго обрабатывается.
4. Наряду с системными таблицами в списке также болтаются имена view, которые были раньше, но которые я уже удалил. Откуда он их берет и как удалить?
5. Можно ли как-то перенастроить связь префиксов с пиктограммами компонентов в part manager? Например по ГОСТ микросхемы принято называть с буквы D (device), а оно при этом показывает диод. А диод по ГОСТ следует маркировать VD, но такой префикс ему вообще неведом.

Почему-то можно явно настраивать только те поля базы, которые имеют тип char, varchar, int. Всякие типы вроде datetime, UUID он не импортирует. Но это удалось сделать через конвертацию данных

Сообщение отредактировал Hoodwin - Feb 29 2012, 14:01

Эскизы прикрепленных изображений

 

[vitan]

1. Правильно ли я понимаю, что столбец БД, указанный конфигуратору как Part_Number (см. рисунок) - это уникальный номер компонента в базе CIS. То есть это не Part Number производителя, потому что теоретически два разных производителя могут выдать одинаковый артикул, в особенности те, кто нумерацию ведет только строками чисел. Смысл этого номера в том, чтобы CIS однозначно мог найти компонент в базе при операциях обновления свойств и т.п. Я поначалу сделал его обычным номером производителя, но сейчас вот думаю перевести его на UUID, который SQL сервер умеет генерировать.

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

Почему-то можно явно настраивать только те поля базы, которые имеют тип char, varchar, int. Всякие типы вроде datetime, UUID он не импортирует. Но это удалось сделать через конвертацию данных

Это везде почти так. Во многих программах, работающих с базами или около них это так. Наверно, для совместимости. Меня тоже бесит, но ничего не поделаешь. Я тоже конвертирую в текст частенько.