[dead_cell 0]

снова практический вопрос.

итак решили как делать, как хранить и прочие заморочки сложные по-началу для понимания :).

пошли дальше, организация самой БД в Access.

есть у нас (нет ну как есть? мы так думаем, что будет) несколько таблиц: резисторы, конденсаторы, коннекторы, микросхемы, транзисторы и т.д....

есть таблица коннекторы, в которой определенный набор параметров (type, pin count, pitch, ... , schematic, footprint, DEVICE, descpription, ...).

разъемы, ни для кого не секрет делятся на типы (коаксиальный, цилиндрический, прямоугольный, D-Sub, винтовые клеммы и проч...).

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

 

как это побороть?

 

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

Изменено 3 августа, 2011 пользователем lazarev andrey

[vitan 2]

итак решили как делать, как хранить и прочие заморочки сложные по-началу для понимания :).

пошли дальше, организация самой БД в Access.

есть у нас (нет ну как есть? мы так думаем, что будет) несколько таблиц: резисторы, конденсаторы, коннекторы, микросхемы, транзисторы и т.д....

Видимо, на своих ошибках все-таки эффективнее учиться. :)

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

[JohnSilver 1]

Ну не дошли мы до этого. Не вижу я удобства в одной таблице.

И ваще, что-то как-то в Access не делается по-быстрому нормальная релятивная база.

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

Вощем, я остыл к этой теме, пользуюсь тем, что есть и особо не парюсь.

[Буратино 0]

Ну не дошли мы до этого. Не вижу я удобства в одной таблице.

Это от того что ваша база (реальная или гипотетически возможная) спроектирована до уровня на котором вносятся данные в систему, а этап с анализом и выборкой информации пока остается "за кадром". Как только понадобится вынимать что-то из БД, вот тогда любое излишнее дробление вылазит боком.

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

 

И ваще, что-то как-то в Access не делается по-быстрому нормальная релятивная база.

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

Вощем, я остыл к этой теме, пользуюсь тем, что есть и особо не парюсь.

Не устаю повторять: Акцесс не хуже, всех остальных инструментов ,все у него есть и даже возможность строить настоящие клиент-серверные решения. Более того, я бы ввел изучения этой программы в первые классы школ. Это удивительная прога ,многогранная и гибкая. С момента выхода "1997" версии ,кто-то там в Микрософте уволился из ведущих разработчиков или менеджеров этой платформы, но даже последние версии еще вполне работоспособны.

Я лично пользуюсь Access как инструментом для решения широкого круга задач, вот например в последний раз строил систему, которая проанализировала слова в даташите на АТМегу32Ю, руководстве на компилятор ИАР и юзер мануале для сликедитора. В качестве результата имею словарь с показателями плотности слов, что-то типа "дисперсии" и алфавитными сортировками, как отдельно по документам/главам/абзацам строкам так и по группе документов из списка. За чашкой чая, и я ведь не программист как бэ.

 

Вощем, я остыл к этой теме, пользуюсь тем, что есть и особо не парюсь.

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

 

снова практический вопрос.

 

Основная таблица/хранилище должна содержать 5полей:

ID Длинное целое

ParentID Длинное целое

Name Текстовый255

Library Ref Текстовый50

Footprint Ref Текстовый50

 

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

 

Если предприятию необходимо что-то кроме того что уже есть - добавить функциональную таблицу(Ы) и связаться по ID

Library Ref , Footprint Ref можно заменить внешними ключами с ссылкой на справочник, но в моем случае достаточно и этого.

Футпринты и УГО хранить в одних файлах а не создавать по 10 штук для каждого типа полупроводника. Вот тогда будет и красота на схемах и порядок на платах.

---

Это вы еще не добрались до перебросов в солидворкс плат ,вот там без правильной БД и обвяза стройного ваще нефиг делать.

[vitan 2]

Дежавю...

Вторую картинку как-то я уже комментировал, похоже.

Не поленюсь и еще раз.

Такая классификация некорректна, ибо она сделана сразу по нескольким признакам.

Корректной считаю, например, такую, как на моей картинке. :)

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

Просто хочу предостеречь новичков...

[JohnSilver 1]

Да, был у нас курс, что то вроде "Программирование .... для магистров". Вроде пытались привить любовь к VB for App. Вот де вам Excell, а вот вам и VB, а теперь мы можем делать с ячейками все, что захотим. Но я удачно отмазался от VB и cдал итоговою работу на VHDL. Не лежит душа к бэйсику, не приживается. Вроде много можно сделать, но как то все кривовато. Может я не умею его готовить? (это риторический вопрос, не надо на него отвечать )

 

Вот скажите, Буратино, если все возможно в Access, почему вы молчите и не подскажете, как решить задачу описанную в посте №№3-5?

 

Если предприятию необходимо...

Ключевая фраза. Ответ - не надо. Думал можно малой кровью сделать для себя немножко поудобнее, но ...

[Буратино 0]

Дежавю...

Вторую картинку как-то я уже комментировал, похоже.

Не поленюсь и еще раз.

Такая классификация некорректна, ибо она сделана сразу по нескольким признакам.

Корректной считаю, например, такую, как на моей картинке. :)

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

Просто хочу предостеречь новичков...

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

 

Да, был у нас курс, что то вроде "Программирование .... для магистров". Вроде пытались привить любовь к VB for App. Вот де вам Excell, а вот вам и VB, а теперь мы можем делать с ячейками все, что захотим. Но я удачно отмазался от VB и cдал итоговою работу на VHDL. Не лежит душа к бэйсику, не приживается. Вроде много можно сделать, но как то все кривовато. Может я не умею его готовить? (это риторический вопрос, не надо на него отвечать )

Да при чем тут бейсик? Фишка Accessa не в VBA, а в SQL + DAO(ADO) . И нет никакой разницы что бейсик что С++, ибо используются методы и свойства объектной модели по доступу к данным из рел. хранилищ. А популярен акцесс в силу своей дружественности и простоты. Немаловажным является поддержка макросов , конструкторов, "быстрых" форм и встроенного генератора отчетов. Ну и VBA нельзя сбрасывать со счетов, чес слово все там для своего времени четка.

 

 

Вот скажите, Буратино, если все возможно в Access, почему вы молчите и не подскажете, как решить задачу описанную в посте №№3-5?

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

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

 

Ключевая фраза. Ответ - не надо. Думал можно малой кровью сделать для себя немножко поудобнее, но ...

Внимательно перечитайте посты вверх: согласитесь, я Вас ни в коем случае не отговариваю от такого решения, я лишь обратил внимание на то, что Microsoft Access тут ни при чем.

[vitan 2]

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

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

 

Более того если даже и увижу то изначально система ориентирована на возможность перестройки и перекомпоновки иерархий, однако в таком случае потеряется связь PCB проектов.

Если за идентификаторы компонентов берется то, что у Вас на картинках в поле NAME, то ясно дело, потеряется. Потому что там, извините, бардак. Чтобы такого не было, надо отличать компоненты по неким уникальным ID. Вы тоже об этом постоянно говорите, но, похоже, Вы думаете, что это ID должно быть простым числом. Если так (нет - поправьте), то советую применять для компонентов не числа, а т.н. корпоративный партнамбер. В качестве него смело можно использовать код заказа компонента из даташита. Этот вопрос уже обсуждался где-то в интернете несколько раз, в т.ч. и здесь, так вот: вряд ли кому-то удастся найти два разных компонента с одинаковым кодом заказа. И это среди всего многообразия. Но я, тем не менее, советую для кодов заказа вести отдельную колонку в таблице. Почему - расскажу, если кому-то это надо.

 

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

Я вспомнил, о чем мы давно говорили. Вы говорили, что в базе надо хранить компоненты в порядке возрастания параметров, чтобы в КД потом писать. Так?

Я тогда уже говорил, что сортировка выполняется совершенно спокойно путем извлечения в запросе столбца со значением емкости, к примеру. При этом никакие цепочки не рвутся, и ГОСТ не нарушается.

[dead_cell 0]

мне вот не совсем понятен момент именно "когда в БД НАДО заводить новый компонент"?

просто кто решает ЧТО надо внести в БД, а что НЕНАДО? тут возникает роль библиотекаря (ну или того, кто внятно может дать ответ на те или иные вопросы по организации самой БД).

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

 

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

 

у нас планируется идентификация компонентов по внутреннему ID, который будет в первую очередь заводиться в БД PDM, после этого, уже с помощью организационных моментов, будет заведен компонент в БД Allegro (схемотехническую). схемотехник конечно может использовать любые библиотеки и компоненты, до момента сдачи проекта в PDM систему, во время сдачи проекта ему предложится верифицировать все компоненты.

 

НО мы отошли от сути :)

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

 

то vitan: не могли бы вы скинуть на емайл просто шаблоны таблицы для понимания, я так понимаю что у вас организовано не в акцессе? но суть я думаю будет ясна. не хочется наступать на грабли :) dead_cell(шабака)mail.ru

Изменено 5 августа, 2011 пользователем lazarev andrey

[vitan 2]

мне вот не совсем понятен момент именно "когда в БД НАДО заводить новый компонент"?

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

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

 

у нас планируется идентификация компонентов по внутреннему ID, который будет в первую очередь заводиться в БД PDM, после этого, уже с помощью организационных моментов, будет заведен компонент в БД Allegro (схемотехническую). схемотехник конечно может использовать любые библиотеки и компоненты, до момента сдачи проекта в PDM систему, во время сдачи проекта ему предложится верифицировать все компоненты.

Правильно, пусть используют, что хотят, но потом верифицируют. Я сам именно так и работаю.

Однако, мне непонятно, зачем городить две разных БД. Какая у Вас PDM?

 

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

Этим должен заниматься не библиотекарь, а архитектор системы, которому совершенно все равно, сколько там таблиц.

 

то vitan: не могли бы вы скинуть на емайл просто шаблоны таблицы для понимания, я так понимаю что у вас организовано не в акцессе? но суть я думаю будет ясна. не хочется наступать на грабли :) dead_cell(шабака)mail.ru

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

 

[Буратино 0]

Если за идентификаторы компонентов берется то, что у Вас на картинках в поле NAME, то ясно дело, потеряется. Потому что там, извините, бардак. Чтобы такого не было, надо отличать компоненты по неким уникальным ID. Вы тоже об этом постоянно говорите, но, похоже, Вы думаете, что это ID должно быть простым числом. Если так (нет - поправьте), то советую применять для компонентов не числа, а т.н. корпоративный партнамбер. В качестве него смело можно использовать код заказа компонента из даташита. Этот вопрос уже обсуждался где-то в интернете несколько раз, в т.ч. и здесь, так вот: вряд ли кому-то удастся найти два разных компонента с одинаковым кодом заказа. И это среди всего многообразия. Но я, тем не менее, советую для кодов заказа вести отдельную колонку в таблице. Почему - расскажу, если кому-то это надо.

 

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

Я вспомнил, о чем мы давно говорили. Вы говорили, что в базе надо хранить компоненты в порядке возрастания параметров, чтобы в КД потом писать. Так?

Я тогда уже говорил, что сортировка выполняется совершенно спокойно путем извлечения в запросе столбца со значением емкости, к примеру. При этом никакие цепочки не рвутся, и ГОСТ не нарушается.

 

Так и я Вам отвечал уже что не получится у вас алфавитно отсортировать номиналы у тех-же резисторов или конденсаторов, судите сами:

Вот например резисторы в алфавитном порядке:

 

0.47R

0R

1.2k

1.5k

100

100k

10k

10R

150

15k

180

1k

1M

1R

2.2k

2.7k

200

20R

220

220k

22k

22R

25R

270

2k

2R

3.3k

33k

33R

3M3

4.7

4.7k

40k

470

470k

47k

47R

540

680k

68R

820

 

 

Вот в порядке номиналов:

 

0R

0.47R

1R

2R

4.7

10R

20R

22R

25R

33R

47R

68R

100

150

180

200

220

270

470

540

820

1k

2k

1.2k

1.5k

2.2k

2.7k

3.3k

4.7k

10k

15k

22k

33k

40k

47k

100k

220k

470k

680k

1M

3M3

[vitan 2]

Повторяю: это наиболее правильный вариант хранения информации о компонентах и их моделях.

Хм. Сами же привели пример, что после небольшого изменения классификаци у Вас потеряется связь с PCB. Если это правильно, то без комментариев.

 

Так и я Вам отвечал уже что не получится у вас алфавитно отсортировать номиналы у тех-же резисторов или конденсаторов, судите сами:

1. Я нигде говорил, что буду сортировать номиналы по алфавиту.

2. То, что Вы привели - не номиналы. Номиналы - это числа. А у Вас смесь из букв и цифр. Это - кодировка номиналов. Типы кодировок, кстати могут быть разные.

3. Если Вам очень хочется сортировать детали в порядке увеличения номиналов, то это делается выведением столбца с _числами_ рядом и сортировкой.

4. Если деталь записывается в список в виде кода заказа (импортная, например), то правило сортировки по номиналу из ГОСТа можно прилепить к этой ситуации с очень большой натяжкой. Гораздо естественне сортировать текст кода заказа, это абсолютно ни у кого проблем не вызывает (видимо, кроме Вас).

5. Подмешивать во внутренний идентификатор путь из классификатора (как на картинке) считаю неверным хотя бы по причине того, что такой идентификатор вряд ли удастся передать в PCB (из-за слешей и длинного имени).

В общем, не путайте понятия партнамбера, номинала и т.п. и все будет хорошо. :)

[dead_cell 0]

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

 

 

Правильно, пусть используют, что хотят, но потом верифицируют. Я сам именно так и работаю.

Однако, мне непонятно, зачем городить две разных БД. Какая у Вас PDM?

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

 

PDM Windchill, как раз тут достался классификатор компонентов по Windchill'у, мозгуемс.

[Буратино 0]

А вот зачем нужна связь базы с готовой платой? После того как я "стянул" компонент на схему и перебросил на PCB мне все равно что там в базе и как он теперь называется. Получается что на этом функции библиотеки кончаются. Если к библиотеке присоед. другие базы то конечно же необходимо обеспечить целостность баз и при смене ID менять внешние ключи в связанных таблицах.

 

1,2,3,4 Хотите вести абсолютно лишнее поле с номиналом в виде цифр - ведите. Хотите иметь перечни/спецификации с кодами заказа вместо номиналов - пожалуйста, а я пока все же останусь при своем мнении. Ведь все получается естественно и органично: ID служит и для построения дерева компонентов и для сортировок внутри группы.

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

 

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

[dead_cell 0]

А вот зачем нужна связь базы с готовой платой? После того как я "стянул" компонент на схему и перебросил на PCB мне все равно что там в базе и как он теперь называется. Получается что на этом функции библиотеки кончаются. Если к библиотеке присоед. другие базы то конечно же необходимо обеспечить целостность баз и при смене ID менять внешние ключи в связанных таблицах.

 

ну а если представить что после разводки или во время, ну в общем после этапа схемотехнического проектирования, конструктор-механик решил поменять некий компонент?

как у вас происходит обмен данными от вас к конструктору и обратно? idf?

 

это я просто для себя, как у кого происходит обмен информацией между ECAD <-> MCAD

Изменено 5 августа, 2011 пользователем lazarev andrey