2. Я говорил не о Libraries а о SCH Library! Часто приходится создавать новое, править старое. Приходится крутить бегунком..

Project/ComponentLink перед любой аннотацией решает эту проблему



Ах там. Мой совет. Не плодите библиотек на миллион компонентов. Одно не ловкое движение при вставке или редактировании нового компонента и все будет испорчено. За одно и этот вопрос пропадет

Качаю, спасибо!

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

Я и пишу о том что иерархия и разделение моделей по разным библиотекам при помощи средств самой файловой системы удобнее, однако менее перспективно! О том почему я так считаю я говорил много раз: в частности это связано с возможностью получения правильных спецификаций и перечней, где помимо очевидных вещей будет присутстовать ,сортировка, группировка и наименования категорий. При разбросе баз данных усложняется администрирование всего этого дела. Также мне симпатишна мысль о том, что я могу в своих компонентах одним махом менять параметры, расположения, длины выводов и принципы выравнивания. Одновременно и для всех компонентов. Нельзя сбрасывать со счетов удобство втягивания компонентов с панели Library на схему, возможность исключить повторы и неопределенности в моделях.
Я не настаиваю на таком подходе, просто мне он нравится

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

Наоборот. попробуйте найти в библиотеке вашей когда изменялся компонент. Можно писать параметр-- но его забывают править. К томуже для посадочного места такого параметра вообще не предусмотрено.
Если в отдельной--- дата изменения файла уже сама говорит об этом.

Вот это и есть самое плохое. все это достаточно индивидуально. и не зачем махом менять. Достаточно сразу правильно вводить, а не бросать компонент наполовину созданным
Удобства абсолютно одинаковы, что раздельно, что в месте. Если есть база

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

На вкус и цвет товарищей нет

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

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

По поводу удобства стягивания компонентов на схему:
Дело втом, что я использую запрос, формируемый "силами" SQL. Результатами работы запроса является подготовленый полуфабрикат для панели либрари. Это удобно и правильно на мой взгляд. В состав этого запроса входят данные из базы. В случае дифференциации модели хранения компонентов получится что этот мой запрос нужно править добавляя в него новые таблицы. Есть еще несколько замечаний, но не буду останавливаться на них подробно, ведь в конце концов такой подход противоречит принципам нормализации БД.

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

---
В качестве аргумента против повторов привожу схему УМЗЧ, которым я занимаюсь в св. время (кстати нет фанатов звука среди нас?) На ней видно что УГО конденсатора одно на схеме, резистора одно на схеме транзистора то же одно.

Я рад за Вас

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

Ну так стаскивайте из базы. кто вам мешает и в том и в другом случае

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

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

Да наздоровье. Это ни как не влияет, в одной, нескольких, и ли в разветвленном дереве хранятся библиотеки.

То есть все что тут написано не затрагивает сути: что лучше -- держать все в одной библиотеки, иди на оборот каждому компоненту по собственной библиотеки.
Истина всегда лежит по середине


Смотрите правила раздела clearance и раздела Via-- скорее всего они запрещают

2. Конечно может быть разной, но зачем? Структура должна быть заточена/подогнана под цели, а что может быть белее точне, чем вид иерархии типа "дерево"? При этом у меня ни разу не отваливались либы, ни разу ничего с ними не происходило, да собствено с чего бы? Кол-во записей? Это пустяки для современных СУБД. Размеры файла? Дак не 2Га и даже не сотни мегабайт получаются. Не понимаю, почему 100 файлов надежнее, чем один!? А с этой сотней ниче не может случиться?
Ну хорошо, пусть допустим упал файл, так есть ведь архивы! Да, нужно будет переделывать некоторую работу (до версии в архиве), но при этом точ такую же (или почти такую же) работу нужно будет проделать и если упал один из 100ни файлов!
В конце- концов, тогда уж правильнее будет нарезать библиотеки кусками, по типу: МоделиУГО_часть1, МоделиУГО_часть2...МоделиУГО_частьn. Работать только с МоделиУГО_частьn ,при этом, при добавлении нового "тома" добавлять его в запросы. Возможно, но у меня на данный момент MainPCB.PcbLib - 6метров, MainSCH.SchLib - 564к и пока рановато нарезать ломтиками такие либы.
Не согласен по поводу надежности, но спорить больше на эту тему не буду.

3. Конечно стаскиваю, но у меня это удобнее и именно потому что все в одной куче (см. картинку) Вам приходится переключаться между библиотеками, и таскать бегунок. Ничего страшного в этом нет, но почему бы не сделать это элегантнее!?

4. Врямя окупилось уже сейчас! Ведь я не только о себе думаю, и проблемы индейцев мне не безразличны Конструктору реально легче так как я ему выдаю специки , перечни и сборочные чертежи. Правильные с групировкой, сортировкой и полными наименованиями компонентов. Не все гладко получается, однако экономится время неделями. Более того в последнее время 3Д модели плат для чертежей получаю, что также помогает и ускоряет работу по созданию КД.
Вы упоминали о том что это не ваш хлеб и оно вас не касается, однако, у меня другая обстановка и другие мотивы.

5. Конечно, именно поэтому на двери ставят доводчики Если есть возможно что-то не делать - делать это не будут Но согласитесь если пользователь работает с компонентом в Альтиуме то средства ОС смогут сохранить отко когда этот файл был создан и модифицирован. Если оно нужно то правильно было бы авторизировать вход в программу альтиум .копировать схематик либу и либу футпринтов, а на этапе выхода из программы сличать файлы и анализировать различия в каждой модели. Найденые отличия записывать в базу данных с идентификатором конкретного пользователя ,в строке конкретной модели.


6. Влияет, так как нужно пересобирать запросы к БД при добавлении/удалении таблиц/файлов при "кучерявой" модели хранения либ.

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

2. я всегда акцентировал только на человеческом факторе. Когда 2 элемента в одной библиотеке-- правя один, можно испортить второй. Больше ни о чем другом. Но именно это повышает или понижает надежность и устойчивость всего в целом.
3. Еще раз. Мне приходится переключаться. Все находится в ОДНОЙ библиотеке--- Ссылке на базу данных. все ищется только в ней.
4. это уже отвлечение. У кого хвост длиннее
5. мне как пользователю нужно чтоб дверь закрывалась. А по какой причине она не закрывается-- это проблемы другие. Работающий в пакете может знать OC-- но не обязан
6. У вас влияет-- у меня нет. у меня просто ищет во всем дереве, а не в конкретном листочке
7. Вот. Уже резать на куски. Я тоже некоторые на оборот группирую. Повторяюсь. Истина по серендине

Владимир, а как именно у вас хранятся либы? На диске есть место внутри которого папками создана иерархия, внутри папок файл или файлы или может быть и то и то? Каких вариантов больше: тех где в одном файле группа компонентов со схожими характеристиками или там где один файл - одна модель?
Потом все это сливается в одну БД?

Примерно так. Есть общие, в основном пассивка. Есть по производителям. В основном микросхемы и соединители.
По характеристикам не объединяю . Все характеристики важны. Только по категориям и производителям.
в основном один файл-- одна группа. Например группа Soic. или NPX

вот

Владимир, тогда по неосторожности можно запороть компонент и в вашем случае, ведь есть либы в которых много позиций "Есть общие, в основном пассивка. Есть по производителям", и риск повредить случайно что-то также присутствует! Работы по востановлению не меньше не больше нужно будет сделать..
Вот вы поделили модели средствами файловой системы, в итоге работая с SCH Library и PCB Library никаких удобств не получили (у меня в связи с хранением всего в одном файле их то же нет, но нет и неудобств связаных с подвязыванием нового/администрированием старого в системе, ведь все в одной куче!)
В самом Libraries вы работаете с чистыми таблицами DBLib, подфильтровывая постоянно что-то и таская бегунок. У меня структура компонентов перед глазами, при этом ровно такая какой она и должна быть при работе с схемой.
Таким образом я трачу силы максимально эффективно, ничего лишнего и ненужного в процессе не делаю. Ориентир на результат в виде КД.

---
Сдавайтесь.

понятие много растяжимое. 2 это уже много.
По памяти я вроде за 2 десятка нигде не перешел. среднестатистическое-- наверное возле 5.
У вас много- это тысячи. Вот и вопрос что запарывается тысяча, или пяток

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

Ошибаетесь. Я ввожу 3-4 характерных символа-- и уже отфильтрованное помещается в окне. бегунок это лишнее. все должно быть в пределах окна. Если не в пределах-- еще символ дописывается

Не важно сколько запарывается, важно сколько нужно потом востанавливать! Если упал файл (напоминаю, что еще ни разу не сталкивался с этим) то можно взять из архива старый (архивы создаются автоматом) и доделать то что отвалилось. В вашем случае также прийдется востанавливать компонент-два, ниче по трудоемкости не меняется!



Лучше всего рассудила бы нас практика. Вот если взять схему на бумаге и перенести ее в схематик Альтиума например.. Я старался сделать этот процесс как можно удобным, и мне кажется, что он получился и более эффективным. Но спорить не буду, имеете право делать по-своему.

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