[Uladzimir 72]

Такие связи ненадежны и недолговечны smile.gif

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

 

А какие связи Надежны и раз и навсегда?

 

[vitan 2]

Замечу. Я ведь не настаиваю на параметре "тип корпуса".

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

Я тоже давно хочу ввести это. Но пока откладываю. :)

 

Да я уж неоднократно писал

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

Ээээ... Я че-то не догоняю. Вы таки за или против деления УГО на библиотеки? Вначале - категорически против, теперь, вроде бы - за...

 

1. С одним справочник на все компоненты не согласен. Мне кажется будет лучше разделить их на каттегории - транзисторы, резисторы, микросхемы, выключатели и т.п. Зачем? В каждой таблице кроме основных полей будут поля, относящиеся к конкретной категории, например, тип транзистора (NPN, PNP, MOSFET-N....). Это пригодится для сортировки и группировки компонентов уже в Альтиуме. Конечно не все параметры будут записываться, а какие-то самые важные.

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

 

2. Если вы имеете ввиду что то вроде этих топологических элементов, то мне кажется это можно будет добавить позже, когда будет более менее отлажено остальное.

Я имею ввиду не это, а справочники других сущностей. И уже начал обсуждение способа хранения сущности "УГО" с Владимиром. Следующим справочником (после окончания обсуждения этого) предлагаю обсудить справочник футпринтов.

__________.rar

[jkrieger 0]

vitan, простите, не дочитал.

 

Сразу выскажу одно "ограничение" так сказать. Для разрабатываемой библиотеки никакого клиента не будет. Ну кроме MS Access для ввода новых компонентов =) Во всяком случае я надеюсь, что можно обойтись только им.

 

Таблица УГО (если можно я буду называть это таблица, как в MS Access). Неуверен что нужно. Разве что для удобства выбора при добавлении компонента. Но то же самое можно сделать и путем выбора из фиксированных значений, не создавая отдельную таблицу.

 

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

 

Таблица производителей. Опять же только для удобства выбора при добавлении ИМХО.

 

Таблица симуляции. Мне очень хочется чтобы была.

 

Что там еще было?

 

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

[тау 31]

А какие связи Надежны и раз и навсегда?

главным преимуществом хранения инфы в базе является контроль целостности.

 

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

В противном случае база будет похожа на эксель "что хочу то и удаляю"

[vitan 2]

Для разрабатываемой библиотеки никакого клиента не будет. Ну кроме MS Access для ввода новых компонентов =) Во всяком случае я надеюсь, что можно обойтись только им.

Согласен. Клиентская часть должна быть на свой вкус.

 

Таблица УГО (если можно я буду называть это таблица, как в MS Access). Неуверен что нужно. Разве что для удобства выбора при добавлении компонента.

Не только. Основная идея в том, чтобы УГО были организованы так же, как это сделано в схемотехническом САПР. Это, имхо, сильно помогает и в повседневной работе, и в автоматизации.

 

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

Правильно. Но еще раз хочу напомнить, что футпринты тоже надо группировать. Причины - выше.

 

Таблица производителей. Опять же только для удобства выбора при добавлении ИМХО.

Из нее у меня вставляются комментарии в КД (кто производитель детали, чтоб легче искать было). А еще рядышком таблица стран. Чтобы понятно было, что свое, а что - нет, и куда за этим ехать. :)

 

Таблица симуляции. Мне очень хочется чтобы была.

Я пока до этого не дошел, но тоже хочу. Я попозже еще Вас помучаю на эту тему? :)

 

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

В общем, согласен. Но мне одно непонятно, как Вы соираетесь обесепчивать целостность данных, если ссылки будут вести вникуда?

 

Да, по поводу таблицы компонентов. Чуть не забыл самое интересное - поле "проверено". :) У меня если там True, то только тогда этот компонент виден в запросе, который исходит от САПР. Т.е. непроверенные компоненты просто физически нельзя поставить на схему. Процесс проверки сделан средствами BPM/Workflow. Работает неплохо, советую. Тут просто были упоминания о некоем "библиотекаре". Думаю, его никогда не появится. А вот организовать коллективную проверку с помощью чего-то подобного, думаю это - самое то.

[jkrieger 0]

vitan, да, про поле Проверено я и забыл. Точно надо.

 

Клиентская часть должна быть на свой вкус.

М.. я например не вижу надобности в каком-то клиенте вообще. Вот прикрепляю рабочее (как мне кажется) решение.

 

Не только. Основная идея в том, чтобы УГО были организованы так же, как это сделано в схемотехническом САПР.

Опять, же. я наверное, вас не понял. Файлы с УГО будут лежать в папке SCH. Эту папку мы будем синхронизировать с SVN. Как-то организовывать их не вижу смысла, разве что может УГО микросхем в отдельную папку вынести, ибо их будет много.

А от БД вроде ничего, кроме имени файла (одно поле) и не требуется.

 

Но мне одно непонятно, как Вы соираетесь обесепчивать целостность данных, если ссылки будут вести вникуда?

Опять же в архиве есть Внешняя база (Склад). Я там сделал связанную таблицу.. Пример конечно кривой, но вроде работает. Хотя я не знаю что нужно от склада =)

 

Я пока до этого не дошел, но тоже хочу. Я попозже еще Вас помучаю на эту тему? :)

Помогу чем смогу, но думаю смогу немногим =)

ACL.ZIP

ACL2000.ZIP

Изменено 30 сентября, 2010 пользователем Jack Krieger

[Uladzimir 72]

Я тоже давно хочу ввести это. Но пока откладываю. :)

 

 

Ээээ... Я че-то не догоняю. Вы таки за или против деления УГО на библиотеки? Вначале - категорически против, теперь, вроде бы - за...

 

 

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

 

 

Я имею ввиду не это, а справочники других сущностей. И уже начал обсуждение способа хранения сущности "УГО" с Владимиром. Следующим справочником (после окончания обсуждения этого) предлагаю обсудить справочник футпринтов.

1. Я уже пользуюсь

2. Вы наверное несколько не в курсе организации библиотек в Altium

База и есть библиотека. и каждая строковая запись-- это компонент.

Вот это держать в одном файле, в одной или несколько таблиц-- это на любителя

УГО и FOTPRINT это тоже библиотеки. Но вот эти изображения лучше держать порознь.

Сделал, проверил, и забыл на все время. Там нечему меняться.

Храните по категориям в отдельных директориях-- никто не мешает

 

Скрин посмотрю позже.

Справочник по Footprint как гиперссылки-- очень даже не против

 

Я тоже давно хочу ввести это. Но пока откладываю. :)

 

 

Ээээ... Я че-то не догоняю. Вы таки за или против деления УГО на библиотеки? Вначале - категорически против, теперь, вроде бы - за...

 

 

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

 

 

Я имею ввиду не это, а справочники других сущностей. И уже начал обсуждение способа хранения сущности "УГО" с Владимиром. Следующим справочником (после окончания обсуждения этого) предлагаю обсудить справочник футпринтов.

1. Я уже пользуюсь

2. Вы наверное несколько не в курсе организации библиотек в Altium

База и есть библиотека. и каждая строковая запись-- это компонент.

Вот это держать в одном файле, в одной или несколько таблиц-- это на любителя

УГО и FOTPRINT это тоже библиотеки. Но вот эти изображения лучше держать порознь.

Сделал, проверил, и забыл на все время. Там нечему меняться.

Храните по категориям в отдельных директориях-- никто не мешает

 

Скрин посмотрю позже.

Справочник по Footprint как гиперссылки-- очень даже не против

[vitan 2]

М.. я например не вижу надобности в каком-то клиенте вообще.

Ну, это дело наживное...

 

Опять, же. я наверное, вас не понял. Файлы с УГО будут лежать в папке SCH. Эту папку мы будем синхронизировать с SVN. Как-то организовывать их не вижу смысла, разве что может УГО микросхем в отдельную папку вынести, ибо их будет много.

Ну, как бы, не знаю... Я всю жизнь работал так: нужен резистор, открываешь библиотеку с резисторами, ставишь УГО на схему. Не надо шариться по одной папке и искать там имя (поиск же по имени будет, я надеюсь, не визуально по форме начертания?). Когда есть деление, то поиск превращается в рпостой и удобный выбор. Когда все свалено в кучу, нужно многое помнить в голове, а это меня напрягает. :)

 

А от БД вроде ничего, кроме имени файла (одно поле) и не требуется.

Не совсем. Я, например, храню в БД соответствие между названием символьной (УГО-шной) библиотеки и префикса позиционного обозначения. Например, резисторы - R, транзисторы - VT. Соответствия брал из ГОСТа. При генерации КД (переченей, ведомостей), т.о. можно легко создавать группы элементов, которые будут иметь человеческие названия. Достаточно отсортировать по поз. обозначению, откинуть цифры и обратиться к базе.

Ну и еще плюс, что можно синхронизировать во времени процессы изменения значений полей в БД и самих УГО.

 

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

Что будет, если из склада удалить какую-нибудь запись, которая есть в других таблицах? Если это возможно, то пример, действительно, кривой.

[Uladzimir 72]

Не совсем. Я, например, храню в БД соответствие между названием символьной (УГО-шной) библиотеки и префикса позиционного обозначения.

Я тоже. Хотя прихожу к мнению-- это лишнее

[vitan 2]

2. Вы наверное несколько не в курсе организации библиотек в Altium

Повторюсь, ни разу в жизни даже не видел альтиума.

 

База и есть библиотека.

и каждая строковая запись-- это компонент.

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

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

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

Библиотекой футпринтов - то же, для футпринтов.

Нет возражений?

 

Вот это держать в одном файле, в одной или несколько таблиц-- это на любителя

Вы простите, но Вас иногда тяжеловато понять. Что именно "это"?

 

УГО и FOTPRINT это тоже библиотеки. Но вот эти изображения лучше держать порознь.

См. выше.

 

Сделал, проверил, и забыл на все время. Там нечему меняться.

Вы настолько непогрешимы? Не допускаете ошибок?

[Uladzimir 72]

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

Хорошо. Придется только сменить название темы.

Так как в алтиуме-- это тоже библиотека. При этой из нее и идет вставка УГО на схему. Или Footprint на pcb

Библиотекой компонентов называть совокупность компонентов, выводимых с помощью запроса (или напрямую из таблицы, что считаю неправильным) в САПР

Вот отсюда и непонятки с Вами. Здесь речь идет как раз о вставки напрямую из таблицы базы

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

Библиотекой футпринтов - то же, для футпринтов.

Вот с этим прямо в точку.

Но отмечу:

Потому как еще существуют файлы библиотек , где УГО футрпринтов, где они хранятся скопом в одном файле. Вот против этого я был против

 

Наверное теперь разобрались?

 

Насчет непогрешимости. Признаюсь. Грешен неоднократно.

Потому и против хранилища в ОДНОМ файле кучи компонентов

 

Ок, определимся с терминами.

Да. вообще с этого и надо начинать. Тут полный консенсус :)

[masterofnature 0]

Повторюсь, ни разу в жизни даже не видел альтиума.

Я думаю, это ключевое замечание.

Если вы не представляете предмета обсуждения, а это не просто БД, а библиотека на основе БД для Altium Designer.

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

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

[vitan 2]

Наверное теперь разобрались?

Нет. Я дал свои определения, но они, похоже, не такие, как Вы ожидали.

Дайте свои (первые два).

 

Потому и против хранилища в ОДНОМ файле кучи компонентов

Не могу понять эту фразу, пока не договоримся о терминах.

 

Master of Nature

Если вы не представляете предмета обсуждения, а это не просто БД, а библиотека на основе БД для Altium Designer.

Я в первом же ответе об этом сказал. Но, Вам не кажется, что Ваши слова "библиотека на основе БД для Altium Designer" и мои "Библиотекой компонентов называть совокупность компонентов, выводимых с помощью запроса (или напрямую из таблицы, что считаю неправильным) в САПР" обозначают одно и то же?

 

Кроме того, в той ветке, откуда все началось, я попросил обобщить накопленный опыт, и опять сказал, что не имею отношения к Альтиуму.

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

Я это расцениваю, как согласие обсудить некую БД _в отрыве_ от альтиума, так сказать, решить задачу в общем виде. Со своей стороны, вроде как, предлагаю помощь и все такое. Давайте уж так и обсуждать, а не сваливаться все время на альтиум! Я же не лезу в Ваш огород со своими САПРами. Думаю, ничего страшного в этом нет?

[Uladzimir 72]

Дайте свои (первые два).

Не могу понять эту фразу, пока не договоримся о терминах.

к сожалению сейчас не обладаю свободным временем

Позже дам.

Я у же говорил, что надо начать с терминов и определений.

Master of Nature

Цитата

Если вы не представляете предмета обсуждения, а это не просто БД, а библиотека на основе БД для Altium Designer

Да. я тоже того же мнения.

Заметьте, те кто знает Алтиум даже не вклинивались в нашу дискуссию.

Для них понятно, о чем речь.

Но это не отменяет правило хорошего тона и надо дать определения, так, чтобы все понимали, о чем речь.

Кроме того, в той ветке, откуда все началось, я попросил обобщить накопленный опыт, и опять сказал, что не имею отношения к Альтиуму.

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

Я это расцениваю, как согласие обсудить некую БД _в отрыве_ от альтиума, так сказать, решить задачу в общем виде. Со своей стороны, вроде как, предлагаю помощь и все такое. Давайте уж так и обсуждать, а не сваливаться все время на альтиум! Я же не лезу в Ваш огород со своими САПРами. Думаю, ничего страшного в этом нет?

О это совершенно не так.

Я только опять зашел в ту тему.

Да, Ваше сообщение было прямо перед моим.Но это не было поводом для открытия мной темы.

Это созрело до того.

Если быть статистиком--я вообще и 10 тем на форуме не создал, а если исключить те, что как модератор делаю, так и пальцев на одной руке достаточно

Так что это чистое совпадение.

 

Но это ведь не повод уйти от обсуждения?

 

 

[vitan 2]

к сожалению сейчас не обладаю свободным временем

Позже дам.

Хм... Разве для этого нужно так много времени?

 

Да. я тоже того же мнения.

Отлично. Тогда Вам - тот же вопрос.

Вам не кажется, что слова "библиотека на основе БД для Altium Designer" и "Библиотекой компонентов называть совокупность компонентов, выводимых с помощью запроса (или напрямую из таблицы, что считаю неправильным) в САПР" обозначают одно и то же?

 

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

 

Но это ведь не повод уйти от обсуждения?

Жду с нетерпением обстоятельных ответов.