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

Ну да. Формально в каждом должно быть проверено.
Флаг УГО проверено
Флаг Footprint проверена
Флаг для любой модели- проверено
флаг для записи в таблице параметров проверено


Это похоже как на FTP.
Раздел, куда заливают все, кому не лень и как попало. Много интересного, много не провереного, много

И папка куда переносят якобы нужное и проверенное.
Почти не пополняется, и тоже не все хорошо, но доверия больше

Вдогонку.
1. Я как пользователь могу, хочу и буду вставлять элементы сразу. Проекты не ждут. а требуют работы.
2. Я как пользователь базы уже не первый год трачу время на заполнения ВСЕХ полей , которые мне известны. ЭТО экономит мне время потом. И я знаю это мне вернется сторицей.
3. Я, как будущий и сознательный пользователь ЭТОЙ базы знаю, и буду заполнять и все параметры и для нее.
4. Наверняка таких, выполняющих 3 пункт будет немного, относительно общего числа пользователей базы.
5. Я поддерживаю Vitan, что пользователям нужно давать доступ к элементу базы только после заполнения обязательных параметров и приучать к этому.
Опытный это обойдет, остальным- на пользу

Все таки вы меня не поняли.

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

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

Теперь понятно. В общем с идеей согласен. Пусть клиент копирует в общую БД новые компоненты.

Только мне не очень нравится идея сделать отстойник (я когда говорил про отстойник имел ввиду общую БД). Такая идеология, кстати, применяется в библиотеках у кейденса. Есть некая временная библиотека и библиотека проверенных компонентов. Между ними происходит перенос компонентов, это делают библиотекари. В нашем случае, конечно, можно было бы заменить библиотекарей на сообщество пользователей, но все равно останутся две "зоны". В одной будет бардак, а в другой изменения будут проводиться очень медленно. В результате все равно плохо.
У нас проект как бы общественный, поэтому ответственность за кривой компонент сбросить будет не на кого. Можно только помочь юзеру в выборе правильного компонента. Для этого предлагаются рейтинги (int).
Кстати, рейтинги нужно будет сделать не только для компонентов, но и для пользователей. Чтобы был показатель, кому можно доверять, а кому - не очень. Вот, например, проверил я компонент, добавил ему очков. А большинство тоже проверило и нашло в нем косяк. Каждый отнял у компонента немного очков. Эти очки надо отнять и у меня. Т.о. мой личный рейтинг уменьшится (если не зайдет в минус вообще) и мне доверять народ будет меньше.
Даешь демократию! Свобода, равенство, братство

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

Не уловил. Хотите сказать, что большинство уйдет в минуса? Так на зеркало неча пенять коли рожа крива.
А как еще оценивать объективность?

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

Ммм..
Здесь видно две задачи: оценить объективность рейтинга и побороть спам.
Пусть минусуют, если заслуженно. Ну и что? Несмотря на это никто не запрещает поюзать компонент от такого заминусованного автора.
А насчет спама я вижу пока реальное решение только в бекапах и откатах.

Что-то мне кажется не будет тут спама.
Не та зона, где хотелось бы поспамить

Ну, не скажите. Вот, у нас была такая история. Человек взял из БД компонент, поставил на плату. Думал, раз в БД лежит, то все ОК. А оно совсем даже было не ОК. Плату пришлось дорабатывать кучей проводов. Потом переразвели, понятно, но было очень неприятно. Т.к. БД планируется сильно коллективная, то легко могут найтись люди, которые могут обидеться, и понаделают гадостей. Бекапы нужны.
Что-то мне подсказывает, кстати, что количество юзеров альтиума у нас в России не такое уж и маленькое.

Да я как-то взял посадочное место из PCAD родной библиотеки.
С тех пор не беру ни откуда.
А если беру- перепроверяю в любом случае.
Тут принцип один. Доверяй, но проверяй.
Я даже собственные старые, вроде бы уже и проверенные, пересматриваю.
Всяко бывает.
А гадости не со зла. Они по другому мыслят.
Бекапы независимо от этого нужны. Тут спору нету

Да... тут похоже уже всё пошло по 2му кругу. Нет. По 3-му кругу :)))

Я с этим согласен, жёсткая мера. И главное неотвратимая. Единственное, что вызвало у многих возражения, - это фраза: . Я постараюсь немножко уточнить её, чтобы она никого не пугала. "Не сразу" - это не значит "через неделю". Это означает лишь последовательность: сначала внёс в общую базу, а потом этим из общей базы воспользовался на общих основаниях. И тут интервал времени может быть в минуту: внёс в базу, этот компонент сразу стал доступен для использования (правда с нулевым рейтингом), тут же применил у себя.

... а вообще... я уже заикался в начале темы, что если у меня не будет возможность работать полностью автономно, то я этой базой пользоваться не смогу. Это в свете того, что мы пытаемся ввести такую жёсткую меру, то мы лишаем возможности работать автономно, что многих оттолкнёт. А если не будет инета? А если сервер с СУБД упадёт? Или хостер прекратит договор или ещё чего (как в своё время было с данным форумом)? Тем более учитывая, что наш проект бесплатный, и никто ни за что не отвечает и никому ничего не обязан и не гарантирует. Тогда работа встанет... А многие из нас занимаются серьёзными проектами, где нельзя допустить подобной вероятности...

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


Идея тоже хорошая. Так пользователю ещё проще. Но есть одно НО: наличие клиента пользователю не будет требоваться. Он продолжает работать с локальными базами. А клиент как шпиён или троян сливает его компоненты в общую базу. Тут возможны 2 причины:
1. Поскольку пользователь продолжает работать с локальными базами, то этого клиента он "поставит как-нибудь потом, когда будет время". Т.е. забьёт на это всё :)
2. Он клиента поставит. И забудет о его существовании. Потом у них админ в сети поменяет параметры инета, клиент перестанет связываться с базой, и пользователь на это забьёт по формулировке п.1 ("когда-нибудь постараюсь разобраться, когда будет время").
Хочу ещё раз навести на мысль, что если наличие постоянного взаимодействия с общей базой не будет обязательным условием, то на эту базу можно будет легко забить ввиду занятости. Она должна вынуждать пользоваться ею. Если сломался инет - настраивать. И прямо сейчас, а не "когда появится свободное время". Потому что иначе дальше работа не пойдёт.
В этом плане лучше оставить последовательность: добавление в общую базу - только потом использование у себя из общей базы. Такой вариант уступает локальному клиенту лишь тем, что локальный клиент автоматически добавляет ваши новые компоненты в общую базу. А в случае указанной выше последовательности компоненты придётся добавлять самому. Но это не так долго и не намного больше действий. И ждать не придётся между добавлением в общую базу и возможностью использовать у себя.

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

Мне эта идея очень нравится! (с рейтингами участников, не с равенством :))) ). Тут появляется бОльшая гибкость, информативность, объективность оценки.


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

Тут не нужно проводить аналогии с рейтингом в торрентах. Это в торрентах нулевой рейтинг лишает права скачивать порнушку :)))) А у нас нулевой рейтинг или даже отрицательный ни на что не влияет, кроме как на понимание уровня доверия к оценкам пользователя. Так что не надо бояться отрицательного рейтинга. Никто никого не пугает.

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

Это точно =)

А потому чтобы не пошли по четвертому кругу мы стараемся написать как нам кажется лучше, а там посмотрим.

Как один из принципов проекта я вижу независимость пользователя от проекта. Не пользователи для проекта, а проект для пользователей. И участие в нем добровольное. Поэтому

такой подход применяться не будет.

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

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


По-моему это случай, когда пользователь не участвует в проекте вовсе =) Не получает от проекта ничего и не дает проекту ничего (клиента то нет).


В последнее время я тоже все больше склоняюсь к идее вот такого вот аналога 3dcontentcentral.com


Теперь отчет о нашей с noxius работе =)
После продолжительного застоя готова новуя версия клиента, котрый теперь состоит из двух программ.

pyclient.exe - служит для загрузки данных с сервера, обработки "под ползователя" и сохранения в CSV или MDB (как и в первой версии, но теперь данные идут правда с сервера =) )

pyuploader - служит для отправки данных на сервер. данные берутся из файла gui.mdb, который имитирует мастер новых компонентов (там форма есть. где можно вводить данные и сохранять в таблицу.) Настоящий пользовательский интерфейс возможно будет разработан чуть позже.

Так что теперь появилась возможность коллективно поиграться с базой проекта =)
Порядок следующий:
1 запускаем pyclient, он должен скачать с сервера то что там есть сейчас (4 резистора)
2 смотрим, создаем по образу и подобию новый компонент в форме gui.mdb
3 запускаем pyuploader, он должен залить на сервер созданный вами компонент
4 очищаем таблицу Components в gui.mdb и переходи к п.1

P.S.: файлы настроек необходимо сохранять в кодировке UTF-8 без сигнатуры, извините. такая вот тонкость =(
Как это сделать в штатном Блокноте я не знаю. Я пользуюсь программкой AkelPad.

Ну и теперь самое главное

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

Начну перечень категорий:

Диоды
Конденсаторы
Индуктивности
Резисторы
Транзисторы
Микросхемы
Микропроцессоры (?)
Разъемы
Переключатели (Выключатели)
Реле
Кварцы и генераторы
...

Добавляйте, критикуйте. Напоминаю, что категория это условная группа компонентов с общими ключевыми параметрами.

Диоды
Тип (шотки, стабилитроны , ююю)
Напряжение (обратное максимальное, )
Пиковый и средний ток
Мощность
Корпус
Для кондеров дополнительно точность и TKE
для резисторов вместо TKE температурная стабильность


Ну и так далее

Участие большинства будет состоять в скачивании.


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



Это не совсем то. Лучше думать про Valor Parts Library или других конкурентов.



Ну а нельзя там как-нибудь включить кодировки 866, 1251 и KOI8, чтобы уж всем удобно было?


А вот эти картиночки не впечатлили?
Вы не хотите сделать иерархию сначала?

Кодировки обязательно будут. В принципе я уже разобрался как их менять.

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

Для чего нужна иерархия? Альтиум не поддерживает иерархию библиотек. Поэтому и не планировалось. Есть ли такая возможность в других сапр?

Я лично ни одного за всю жизнь не видел. Но это не значит, что она не нужна, не так ли?
Повторюсь еще раз: иерархия дает возможность наследовать параметры и группы параметров от верхнего уровня к нижним. Почитайте еще раз пост номер 9 и поглядите на картинку из поста 47.
Это упрощает управление библиотеками (когда их много), наводит порядок в голове, и экономит место на диске. Да, ценой потери времени на обдумывание, но ведь мы же никуда не спешим?

Это понятно
Чувствуется порядок не только в организации построения базы, но и нахождении ссылок на все свое сообщения

Прикалываетесь? Зря, скоро мои цитатники обойдут в продаже Мао Цзе Дуна! )
Линк на то и существует, чтобы не писать два раза.
Ну, не хотите иерархию, так и скажите.

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

Да, хорошо, что заговорили о производителях. Они, как известно, любят объединяться и менять имена. Это надо как-то обрабатывать. Есть мысли?

Не, даже в мыслях не было

Хочу.

Я только про базу и думал. Именно в ней иерархию можно и нужно делать

Так чего там. производитель номер 15 был далласом, стал максимом с 35 числа оного месяца, когда в записи базы номер 15 по производителям изменили соответствующую запись.
Хотя хоть производитель и изменил название, его старая позиция, котороя сделана и лежит на мкладах поставщиков-- еще годами под старым именеи продается--- тут больше проблема

Лично я не вижу необходимости в иерархии. Как было для одного компонента несколько полей, так они и останутся. Тем более в результате все равно будем раскладывать в flat-таблицы.

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

Перечень производителей будет. Руками набирать не придется. Собственно некоторые технические моменты мы обсуждаем в таком вот документе. У кого есть желание - присоединяйтесь.

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



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



Ну про проблемы мы все и так знаем. Надо думать о решениях. Я пока с ходу ничего не придумал, кроме создания неких групп производителей, в которые можно будет вписывать таких обхединившихся\переименованных производителей. И применять для компонента в поле "производитель" не ссылку на него самого, а ссылку на группу...


Я бы Вам посоветовал обсуждения вести на форуме, а не в документе. Читать практически невозможно. Пусть будет документ, но только с результатом. На формуе и участников больше, и т.п.

Мне из этого документа запала такая фраза:
Все верно, только разработчики должны применять правильные компоненты. Цена ошибки высока. А проверять больше некому. Поэтому возникла такая мысль: перед применением компонента обязать пользователя проверить его, или, как минимум, выставить компоненту рейтинг (оценку).
Технически это можно попробовать сделать в момент генерации библиотеки (файлика CSV) для САПР. Если юзер его генерит, значит, он хочет применить компоненты в САПР. Можно выдавать в этот файлик только те компоненты, которым он проставил рейтинг. Как мысль? Мне нравится.

Вообще, чуть не забыли о главном: схему данных и структуру БД в студию!

Ну пожелания пожеланиями, а аргументы аргументами. Данные для САПР раскладываются в плоские таблицы, передаются тоже в "плоском" виде, то есть покомпонентно (во всяком случае пока).

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


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


Вариант. Однако представьте, что вы присоединились к проекту чуть позже.В БД уже достаточно много компонентов и вам в первый раз нужно будет проверить их все. Ну и с другой стороны, часто ли вы читаете предупреждения в разных программах? Жмете Дальше и все =) Вот по личному опыту знаю, что так редко кто следует инструкциям. Так что и рейтинг будут скорее проклацывать не глядя.
Вот если б как то отслеживать какие именно компоненты применил пользователь. Это был бы идеальный вариант.


Дык вот нет ее еще =) Предварительно: будет на каждую категорию одна плоская таблица, плюс таблица корпусов, таблица моделей (SPICE), возможно УГО, таблица производителей. Это минимум.

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


Без SQL в реляционных БД делать нечего. Да, у меня так и есть, все компоненты лежат в одной таблице независимо от категорий. Рядом лежат таблицы со структурой каталогов и есть связующие таблицы между ними. Я приводил выше свою структуру в PDF.


Все правильно. Самое главное - это отследить, какие компоненты применил пользователь. У нас нет и не будет никакой возможности сделать такое отслеживание _после_ того, как он их применил. Чтобы это сделать, надо перехватывать момент установки компонента на схему. Эта работа имеет мало общего с БД, а еще проблем добавляет САПРонезависимость.
Поэтому я и предлагаю упредительный вариант. Если не хочешь применять компоненты в САПР, а хочешь просто полазить в клиенте - пожалуйста! Но, как только захотел взять что-то себе в проект - будь добр дать что-то взамен. Т.е., проверить какие-то компоненты. Не обязательно проверять (ставить рейтинг) всем компонентам, можно разрешать генерацию CSV уже после проверки всего нескольких, но это не суть.
Говорите, рейтинг будут лениво пощелкивать? Да пожалуйста! Это палка о двух концах: если среди проверенных таким образом компонентов окажутся плохие, то это обязательно пойдет такому халявщику в минус, как мы выше обсудили. Ну и, в конце концов, никто не запрещает применять компоненты с _любым_ рейтингом.
По-моему, все сходится.


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

Нет уж. Путь лучше поляпает по ссылка гугла, нарабатывая посещаемость,
Иначе будут ставить оценки лишь бы ставить для получения компонента.
Нам такие оценки не нужны

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

Вообще, эта система с рейтингами, конечно, сильно "демократизированная". При любом алгоритме вычисления рейтинга компонента в этой системе основой будет являться мнение большинства. В этом тоже проблема, т.к. чаще всего большинство неправо.
Поэтому надо придумать более объективные критерии для репутации пользователя. Например, можно попробовать вычислять репутацию по сумме нескольких составляющих:
- учитывать значение рейтинга компонентов, которое выставили другие пользователи (для компонентов, которые проверил данный пользователь) - исходная идея;
- учитывать количество изменений в компонентах, инициированных как самим пользователем, так и другими (которые правят его ошибки);
- учитывать количество пользователей, использовавших компоненты, которые проверил данный пользователь, без изменений (в том виде, как он их проверил и\или исправил).
И т.п.
Но, главное, все должны знать, что все это _никак_ не снимает ответственности за применение компонентов. Хотя, вроде, это и так ясно...

Да спору надо. Но не для провокации выставления оценки по нужде.

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

Потом вообще получаешь без оценок, если ранг превысил все разумные пределы-- Значит твои компоненты и так приносят пользу, зачем чтоб он еще что либо оценивал.
Захочешь оценишь.. Твои оценки и так на вес золота

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

О, у "Паханов" система однако еще более жесткая,
Чуть что не так и курлык-мурлы

Ну.. управление это очень расплывчатое понятие. Как по мне, то чего ими управлять-то?


Ну, это была лишь одной из причин. Есть такая полу-шуточная рекомендация по написанию программ в питоне - The Zen of Python. И там есть строка: Simple is better than complex. В разных таблицах сделать проще. Потому не было смысла огород городить. =)


А вот это уже аргумент! Честно, я как то даже не подумал, что можно сделать параметры динамическими. Как собственно в Альтиуме и сделано. Над этим стоит подумать.

Дык это ж и есть управляемость! Вы смотрели таки на скриншот? Видели там пимпочки + и - ? Вот ими все и делается!

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

А что именно в альтиуме сделано динамически? Там можно создавать некие группы компонентов с переменным количеством параметров что ли?


Иногда это еще называют KISS. Keep it simple, stupid! LOL
Хотите превратиться в амебу? Шутю.

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

P.S. Правда тут ограничение - все параметры будут текстовыми. Либо надо дальше усложнять систему.

Так это в любом САПРе есть, даже в пикаде. Я же говорю о том, что набор параметров управляется пользователями на уровне библиотек, а не компонентов.


Это почему, интересно? В чем трудности-то?
А! Догадываюсь. Непонятно, как хранить параметры разных типов в одних и тех же таблицах. Посмотрите внимательно еще раз на другой скриншот. Который со структурой. Там у меня текстовые параметры хранятся в одной таблице, а числовые - в другой. Но это - пока, мне этого мало. В середине топика я уже писал про необходимость усовершенствования типизации. Да, схема данных усложнится, но меня это совершенно не напрягает. Когда мне нужно решение, я его добиваюсь.
Если хотите, можем обсудить типизацию параметров более подробно, мне это интересно. Конкретно интересно, какие типы данных нужны для описания компонентов.
Пока я вижу след.:
- текст;
- число;
- массив чисел;
- частный случай массива - три значения: min, typ, max;
- диапазон;
- условное значение (ток потребления@температура).
Ну и еще нужна группировка параметров в наборы по смыслу (по областям применения): схемотехникам одно, конструкторам - другое... Ну, не буду снова повторяться...

Вот я начал новую жизнь.
Что за пару недель получилось.
Тут только директории. Ну они наполнены тем, что я использую.
В моих типоразмерах, сетках и атрибутах

Доброго дня!

Несмотря на череду праздников и командировок, разработка проекта хоть и медленно, но продвигается. Пришло время поделиться с вами результатами и показать очередную версию клиента для проекта (он же Мастер Компонентов).

Features:

В этой версии есть возможность добавлять новые компоненты в БД на сервере, скачивать компоненты, добавленные другими пользователями, а также экспортировать эти компоненты в таблицы MDB. Настройка экспорта производится в файле 'data.ini'. О том что значат все эти поля подробнее тут.

Для участия в ”тест-драйве” необходимо зарегистрироваться тут.
ВНИМАНИЕ! Пароли хранятся в открытом виде - не используйте свои личные пароли.
Эти логин и пароль необходимо будет указать в секции [ACCOUNT] в файле 'pyclient.ini', также там можно настроить прокси, если нужно. Можно конечно и не регистрироваться, а использовать демо-аккаунт 'user/user', но так ведь неинтересно ;-)

Все действия на данный момент совершаются вручную при помощи четырех кнопок:
Add - добавление нового компонента (во внутреннюю БД)
Download - загрузка новых компонентов с сервера (во внутреннюю БД)
Upload - отправка новых компонентов на сервер
Export - генерация MDB файла, предназначенного для подключения к CAD.

Назначение остальных элементов управления думаю понятно из надписей.

Пока что программа не умеет передавать файлы на сервер, поэтому небольшой набор символов и футпринтов прилагается в архиве с программой в папке 'export'. Там же и демонстрационная библиотека user.DbLib, которую можно подключить к Altium.

Known issues:

- клиент не умеет обновлять записи в БД: если компонент с таким именем уже существует, то новый добавлен не будет;

- не реализовано создание корпусов, символов и моделей: пока что, выбирая символ, корпус или модель, вы выбираете соответственно лишь файл SchLib, PcbLib и .mdl / .ckt. (однин на компонент);

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

- есть проблема с часовыми поясами, т.е. новые компоненты могут быть загружены с сервера повторно из-за разницы во времени; но это не влияет на остальной функционал;

- наименование опций в '.ini' файлах нужно писать в нижнем регистре, а названия секций - в верхнем.


Future:

Сейчас уже стало понятно, что в том первоначальном виде проект нежизнеспособен. Напомню, раньше планировалось, что данные о компонентах будут храниться в базе данных MySQL на сервере noxius.ru (как это сейчас и сделано), а файлы (символы, футпринты, модели) - под системой контроля версий (mercurial) на хостинге Google, и передаваться соответственно при помощи своего клиента.

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

Отсюда вытекает два варианта:

1. Хранить файлы на том же хостинге, где MySQL база (noxius.ru) и передавать их самим клиентом (Мастером Компонентов).

В этом случае нам нужно научиться передавать файлы от пользователя на сервер и обратно (написать этот функционал).
Кроме того, как показала практика, нехватает некоего Менеджера Компонентов, где пользователь мог бы просматривать весь перечень компонентов, символов, корпусов и моделей, которые у него есть в распоряжении, редактировать их, проверять; и инструмента для сравнения двух версий компонентов.

2. Хранить все данные под контролем версий на Google Project Hosting (или может github).

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

Управление своей библиотекой сведется к тому, что вам нужно, используя инструментарий TortoiseHg, получить у себя на диске необходимые вам версии файлов (xml + CAD's). А Мастер Компонентов из этих файлов сгенерирует вам CSV-файлы или MDB-таблицы для подключения к CAD.

К минусам такого подхода относится высокий уровень входа. Для новичков mercurial может оказаться непонятной и сложной системой.



Лично я склоняюсь ко второму варианту. Мне кажется что распределенные системы контроля верий (mercurial, git) вполне подходят для создания открытой библиотеки компонентов.

Спасибо, что дочитали. Хочу услышать ваше мнение по какому пути следует двигаться?

Мы здесь что-то стараемся, обсуждаем. А люди уже во всю выпускают: http://www.rodnik.ru/news/index.php?ELEMENT_ID=1275
Возможно, и наши идеи там оказываются помаленьку.

так этой новости старше лет, чем началу обсуждения этой.
мое мнение
По библиотекам-- ко мне столько приходит, и проверенных-- иногда пользуюсь в части Footprint и только.
А так все равно доработка.
Вот если IPC или ГОСТ выпустит и скажет юзать только такое-- и то не пойдеть.

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

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

Добрый день.
Подскажите, пожалуйста, как зарегистрироваться для участия в ”тест-драйве”. При нажатии на "тут" - не понятно куда отправляют.
Всех с Рождеством!

YUDSV, я извиняюсь что так поздно отвечаю. Работа над проектом сейчас правктически не ведется. Хотя я пользуюсь этими репозиториями и мастером компонентов. Если еще интересуетесь, можем попробовать вместе.

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

А также необходимо скачать мастер компонентов для данного проекта. Назначение, принцип его работы, а также ссылки для скачивания - в статье на we.easyelectronics.ru.

По всем вопросам можете писать мне на jack.krieger(at)gmail.com

YUDSV, я извиняюсь что так поздно отвечаю. Работа над проектом сейчас правктически не ведется. Хотя я пользуюсь этими репозиториями и мастером компонентов. Если еще интересуетесь, можем попробовать вместе.

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

А также необходимо скачать мастер компонентов для данного проекта. Назначение, принцип его работы, а также ссылки для скачивания - в статье на we.easyelectronics.ru.

По всем вопросам можете писать мне на jack.krieger(at)gmail.com