[Krys 2]

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

 

Вот здесь самый интересный момент! Пользователь должен не сразу получить готовый компонент. Он должен его отправить в общую БД, а только потом экспортировать из общей БД обновленную локальную библиотеку. Иного способа добавить компонент в локальную библиотеку быть не должно. Только так юзеров можно будет заставить работать с общей БД.

Я с этим согласен, жёсткая мера. И главное неотвратимая. Единственное, что вызвало у многих возражения, - это фраза:

не сразу получить готовый компонент

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

 

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

 

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

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

 

 

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

Идея тоже хорошая. Так пользователю ещё проще. Но есть одно НО: наличие клиента пользователю не будет требоваться. Он продолжает работать с локальными базами. А клиент как шпиён или троян сливает его компоненты в общую базу. Тут возможны 2 причины:

1. Поскольку пользователь продолжает работать с локальными базами, то этого клиента он "поставит как-нибудь потом, когда будет время". Т.е. забьёт на это всё :)

2. Он клиента поставит. И забудет о его существовании. Потом у них админ в сети поменяет параметры инета, клиент перестанет связываться с базой, и пользователь на это забьёт по формулировке п.1 ("когда-нибудь постараюсь разобраться, когда будет время").

Хочу ещё раз навести на мысль, что если наличие постоянного взаимодействия с общей базой не будет обязательным условием, то на эту базу можно будет легко забить ввиду занятости. Она должна вынуждать пользоваться ею. Если сломался инет - настраивать. И прямо сейчас, а не "когда появится свободное время". Потому что иначе дальше работа не пойдёт.

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

 

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

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

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

 

Кстати, рейтинги нужно будет сделать не только для компонентов, но и для пользователей. Чтобы был показатель, кому можно доверять, а кому - не очень. Вот, например, проверил я компонент, добавил ему очков. А большинство тоже проверило и нашло в нем косяк. Каждый отнял у компонента немного очков. Эти очки надо отнять и у меня. Т.о. мой личный рейтинг уменьшится (если не зайдет в минус вообще) и мне доверять народ будет меньше.

Даешь демократию! Свобода, равенство, братство:)

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

 

 

Ну так черных шаров по сговору накидают.

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

Так что специально накидать человеку чёрных шаров просто чисто технически не получится.

 

Но и пугать не надо. А то по первому разу ктось выложит-- у тут бах по голове- и ты на всю жизнь заминусован :)

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

 

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

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

[jkrieger 0]

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

Это точно =)

 

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

 

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

Хочу ещё раз навести на мысль, что если наличие постоянного взаимодействия с общей базой не будет обязательным условием, то на эту базу можно будет легко забить ввиду занятости. Она должна вынуждать пользоваться ею. Если сломался инет - настраивать. И прямо сейчас, а не "когда появится свободное время". Потому что иначе дальше работа не пойдёт.

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

 

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

 

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

 

Идея тоже хорошая. Так пользователю ещё проще. Но есть одно НО: наличие клиента пользователю не будет требоваться. Он продолжает работать с локальными базами. А клиент как шпиён или троян сливает его компоненты в общую базу. Тут возможны 2 причины:

1. Поскольку пользователь продолжает работать с локальными базами, то этого клиента он "поставит как-нибудь потом, когда будет время". Т.е. забьёт на это всё :)

2. Он клиента поставит. И забудет о его существовании. Потом у них админ в сети поменяет параметры инета, клиент перестанет связываться с базой, и пользователь на это забьёт по формулировке п.1 ("когда-нибудь постараюсь разобраться, когда будет время").

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

 

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

В последнее время я тоже все больше склоняюсь к идее вот такого вот аналога 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.

 

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

 

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

Пожалуйста, давайте обсудим этот вопрос.

 

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

 

Диоды

Конденсаторы

Индуктивности

Резисторы

Транзисторы

Микросхемы

Микропроцессоры (?)

Разъемы

Переключатели (Выключатели)

Реле

Кварцы и генераторы

...

 

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

pyclient.zip

[Uladzimir 80]

Диоды

Тип (шотки, стабилитроны , ююю)

Напряжение (обратное максимальное, )

Пиковый и средний ток

Мощность

Корпус

Для кондеров дополнительно точность и TKE

для резисторов вместо TKE температурная стабильность

 

 

Ну и так далее

 

 

 

 

[vitan 2]

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

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

 

Будет примерно так: "создал-(клиент попробовал залить, если не получилось - отложил отправку на будущее)-применил".

 

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

А потом еще отложил, потом еще, а потом забил.

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

 

 

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

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

 

 

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

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

 

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

Пожалуйста, давайте обсудим этот вопрос.

А вот эти картиночки не впечатлили?

Вы не хотите сделать иерархию сначала?

[jkrieger 0]

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

 

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

 

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

 

[vitan 2]

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

Я лично ни одного за всю жизнь не видел. Но это не значит, что она не нужна, не так ли?

Повторюсь еще раз: иерархия дает возможность наследовать параметры и группы параметров от верхнего уровня к нижним. Почитайте еще раз пост номер 9 и поглядите на картинку из поста 47.

Это упрощает управление библиотеками (когда их много), наводит порядок в голове, и экономит место на диске. Да, ценой потери времени на обдумывание, но ведь мы же никуда не спешим? ;)

[Uladzimir 80]

Повторюсь еще раз: иерархия дает возможность наследовать параметры и группы параметров от верхнего уровня к нижним.

Это понятно

Почитайте еще раз....

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

 

 

 

[vitan 2]

Это понятно

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

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

Линк на то и существует, чтобы не писать два раза.

Ну, не хотите иерархию, так и скажите.

 

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

 

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

 

[Uladzimir 80]

Прикалываетесь?

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

Ну, не хотите иерархию, так и скажите.

Хочу.

Кстати, это касается и базы данных.

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

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

 

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

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

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

[jkrieger 0]

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

 

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

 

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

 

[vitan 2]

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

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

Хочу.

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

 

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

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

 

 

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

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

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

 

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

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

 

Мне из этого документа запала такая фраза:

Разработчики должны работать, а не проверять компоненты.

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

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

 

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

[jkrieger 0]

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

...

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

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

 

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

 

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

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

 

Мне из этого документа запала такая фраза:

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

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

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

Вот если б как то отслеживать какие именно компоненты применил пользователь. Это был бы идеальный вариант.

 

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

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

[vitan 2]

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

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

 

Далее. Именно о запросах мне и интересно узнать.

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

 

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

Вот если б как то отслеживать какие именно компоненты применил пользователь. Это был бы идеальный вариант.

Все правильно. Самое главное - это отследить, какие компоненты применил пользователь. У нас нет и не будет никакой возможности сделать такое отслеживание _после_ того, как он их применил. Чтобы это сделать, надо перехватывать момент установки компонента на схему. Эта работа имеет мало общего с БД, а еще проблем добавляет САПРонезависимость.

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

Говорите, рейтинг будут лениво пощелкивать? Да пожалуйста! Это палка о двух концах: если среди проверенных таким образом компонентов окажутся плохие, то это обязательно пойдет такому халявщику в минус, как мы выше обсудили. Ну и, в конце концов, никто не запрещает применять компоненты с _любым_ рейтингом.

По-моему, все сходится.

 

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

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

Признайтесь, Вы решили хранить их по отдельным таблицам только из-за незнания SQL. :) Никуда не денетесь, придется изучить. :)

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

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

[Uladzimir 80]

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

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

Иначе будут ставить оценки лишь бы ставить для получения компонента.

Нам такие оценки не нужны

[vitan 2]

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

Иначе будут ставить оценки лишь бы ставить для получения компонента.

Нам такие оценки не нужны

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

 

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

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

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

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

- учитывать количество пользователей, использовавших компоненты, которые проверил данный пользователь, без изменений (в том виде, как он их проверил и\или исправил).

И т.п.

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