БД для 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 тут ни при чем.