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

[Hoodwin]

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

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

[Hoodwin]

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

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

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

А что за концепция read-only свойств?

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

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

Ну вот есть мысли накалякать морду на php, кое-какой опыт работы с другими базами на SQL через тонкий клиент есть, и в целом это довольно быстрый способ развития сервисов базы, не только для CIS.

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

Кстати, в CIS с помощью View в SQL можно запросто сделать классификатор с множественным вхождением одного компонента в несколько веток классификатора, сохранив при этом единственный источник исходных данных, избежав ручного дублирования. Не знаю, как насчет CSV, но думаю, что со статическими таблицами такое будет невозможно. Но это так, вспомнилось по мотивам того обсуждения в 2010 году.

[vitan]

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

Получается, что это внутренний документ у закупщиков? Тогда имхо CIS может помочь только в извлечении параметров компонентов при необходимости. Но составлять этот документ надо имхо, все-таки в той же 1С или в другой складской программе.
Естественно, должна быть связь между ними. Но тут дело осложняется в случае мелкого пассива, который обычно заказывают в параметрической форме. Чтобы это работало нормально, надо, чтобы CIS поддерживал формирование строки параметров.

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

Вот его-то я и называю строкой параметров. Пока не реализовано, к сожалению...

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

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

Ну вот есть мысли накалякать морду на php, кое-какой опыт работы с другими базами на SQL через тонкий клиент есть, и в целом это довольно быстрый способ развития сервисов базы, не только для CIS.

Я бы пошел дальше, и не стал ничего писать. В свое время написали, теперь не знаем, что с ним делать. Возьмите лучше сразу менторовский DMS, или, еще лучше, делайте все через Ваш Лоцман. Будет единый интерфейс и стиль работы со всеми объектами проектирования, с компонентами, винтиками, комплексами и т.п.