БД для Allegro CIS, Практические вопросы, от простого к сложному. Опции

[John Silver]

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

Сейчас насущный вопрос:
Сделать релятивную базу в Access по следующей схеме


1 Как сделать запрос, что бы сохранилась возможность задавать несколько корпусов для одного резистора?
Простой запрос не позволяет этого сделать

Код

SELECT Resistor.[Part Number], Resistor.[Part Type], Resistor.Value, Resistor.Tolerance, Resistor.[Schematic Part], Footprint.Footprint, Resistor.[Part name], Resistor.Value1, Resistor.Manufacturer
     FROM Footprint INNER JOIN Resistor ON Footprint.Footprint_ID = Resistor.Footprint_ID;

[John Silver]

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

[Буратино]

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

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

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

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

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

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

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

Основная таблица/хранилище должна содержать 5полей:
ID Длинное целое
ParentID Длинное целое
Name Текстовый255
Library Ref Текстовый50
Footprint Ref Текстовый50

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

Если предприятию необходимо что-то кроме того что уже есть - добавить функциональную таблицу(Ы) и связаться по ID
Library Ref , Footprint Ref можно заменить внешними ключами с ссылкой на справочник, но в моем случае достаточно и этого.
Футпринты и УГО хранить в одних файлах а не создавать по 10 штук для каждого типа полупроводника. Вот тогда будет и красота на схемах и порядок на платах.
---
Это вы еще не добрались до перебросов в солидворкс плат ,вот там без правильной БД и обвяза стройного ваще нефиг делать.

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

 

[vitan]

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

[Буратино]

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

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

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

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

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

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

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

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

[vitan]

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

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

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

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

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

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

[Буратино]

Если за идентификаторы компонентов берется то, что у Вас на картинках в поле 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

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