[Uladzimir 93]

Алтиум с ним и Farnell Newark Аllied поддерживает на автомате. За деньги или нет не знаю. Наверняка каккоето соглашение есть, так как это и реклама

Но базы и поиск по ним доступен, так что каждый может писать свою припампасу

[Krys 2]

Ага! Пошли по второму кругу?

 

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

Мы же собрались делать общий проект.

 

Если добавлять компоненты в локальную базу, то снова встают вопросы переноса их в общую. Их, вроде, уже обсудили.

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

Можно против каждого пункта делать пометки "железно", "предварительно" и т.п.

 

[masterofnature 0]

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

Можно против каждого пункта делать пометки "железно", "предварительно" и т.п.

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

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

[Uladzimir 93]

Да я уж где то начал. Ладно буду где то фиксить.

Белым-что только набрано

Желтым- в стадии обсуждения

Зеленое- принято большинством

красное- отторгнуто большинством.

Если буду вечером свободен, так и начну.

Тута еще и по структуре дерева обещался.

Ох. Всем должен :(

[vitan 2]

Но жизнь сложна. Как быть если ветки дерева перекрестились, срослись, имеют разных прародителей?

Я тут подумал на эту тему, а также на тему "хочу группировать резисторы по 0603, 0805..." и понял, что можно обойтись без упрощения ситуации.

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

Насчет группировки по корпусам и т.п.

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

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

Работа начата, за "толчок" :) спасибо участникам обсуждения!

[Uladzimir 93]

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

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

Насчет группировки по корпусам и т.п.

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

Ну просто замечательно. И волки сыты, и овцы целы :)

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

Работа начата, за "толчок" спасибо участникам обсуждения!

Ну вот, на 22 странице обсуждения родились первые положительные результаты, точнее отзыва о результатах.

Если б так было по всем веткам :(

[vitan 2]

или взять из 2 или более мест, объединив параметры компонента из нескольких веток.

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

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

 

Ну вот, на 22 странице обсуждения родились первые положительные результаты, точнее отзыва о результатах.

Если б так было по всем веткам :(

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

[Uladzimir 93]

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

Так объедините их только в запросе. Для юзера все ведь делается только по запросу

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

Не стоит. Интерес народа заключается только в халяве

А вот интерес отдельно взятых-- тут уж можно придумать

[vitan 2]

Так объедините их только в запросе. Для юзера все ведь делается только по запросу

С этим-то проблем нет. Это ясно. Проблема у меня пока в том, что на данный момент отношение каталогов к библиотекам у меня - это один-ко-многим. Переделка на многие-ко-многим (чтобы указывать не одну закрепленную библиотеку, а несколько: обычную, и "объединенную с другим каталогом") потребует неплохой переработки клиента, процедур и т.п. :(

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

[Uladzimir 93]

С этим-то проблем нет. Это ясно. Проблема у меня пока в том, что на данный момент отношение каталогов к библиотекам у меня - это один-ко-многим. Переделка на многие-ко-многим (чтобы указывать не одну закрепленную библиотеку, а несколько: обычную, и "объединенную с другим каталогом") потребует неплохой переработки клиента, процедур и т.п. :(

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

 

Гм. Опять термины. Каталог- Это таблица с параметрами и ссылками?

Или плюс к этому и библиотеки УГО и прочего.

Если таблицы-- так ничего не надо переделать. Формально компонент присутствует в разных каталогах, ссылки которых указывают на ОДИН УГО, но скажем на разные таблицы параметров.

Черт сам уже запутался :)

[vitan 2]

Черт сам уже запутался :)

Спокойно. :) Посмотрите на скриншот. :) Там подписано, где каталоги, а где библиотеки компонентов.

Каталоги - это каталоги классификатора. Они нужны, чтобы организовать дерево и применить наследование параметров.

Библиотеки УГО и библиотеки футпринтов на скриншоте не показаны. Ими, кстати, управлять намного проще. У меня они просто перечисляются в своих таблицах (справочниках), не имея никакого деления на ветки и деревья. Просто списки библиотек УГО и библиотек футпринтов.

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

Проясняется? :)

[Uladzimir 93]

Проясняется? :)

Когда растут три березы, это уже лес :)

Да эт когда писал, тогда к концу фразы заблудился

[Буратино 0]

Что вы тогда предлагаете?

 

Я неоднократно выражал свою позицию по данному вопросу.

Я, за минимальную базу с однозначно идентифицируемыми моделями, за которые в будущем можно будет зацепиться сторонними/специализированными базами/программами.

К общему знаменателю можно будет прийти только на таких позициях. Обратите внимание, ведь из обсуждения выпали практически все, за исключением тех людей, которые делают систему для/под себя. :laughing:

 

Изменено 29 октября, 2010 пользователем Буратино

[jkrieger 0]

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

 

Модели будут идентифицироваться однозначно. (Я предлагаю и настаиваю на комбинации полей "Manufacturer" и "Manufactrer Number"). У пользователя компоненты будут храниться в виде удобном пользователю, либо в MDB, либо в CSV, либо в другой СУБД. Пока я написал экспорт только для упомянутых двух. Так что "зацепиться" будет не проблема.

 

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

 

Вот мое предложение как это будет выглядеть: схема для наглядности (я ее уже приводил), и клиент в прикрепленном архиве. Это только первые наброски, но думаю они помогут понять куда копать дальше.

 

Роль клиента - забрать данные с сервера по HTTP, и записать в пользовательский источник данных. В 'config.ini' можно выбрать какой источник данных (frontend) вы хотите использовать: CSV или MS Access. Так как у нас нет ни даже заготовки общей БД, ни человека. который бы разбирался в этом, то сейчас 'pyclient' берет данные из аксесовской базы 'global.mdb'. И записывает в 'local.mdb' или 'local.csv'.

 

Между получением данных и их записью будет предусмотрена настраиваемая обработка. То есть из фиксированного набора полей, присылаемых с сервера вы сможете, например, удалить ненужные вам поля, добавить к полю "Voltage" букву "В", поменять запятые на точки, склеить два поля и т.д.

Думаю такой подход позволит так сказать расширить аудиторию =)

 

 

Кроме того, я проверил как ведет себя альтиум с большими таблицами. Сгенерировал таблицу на 8500+ компонентов. Сделал две DBLib, одну подключил напрямую к статической таблице, другую к динамической, генерируемой запросом. Альтиум открывает эти библиотеки около 3-х секунд. Неприятно, но разницы между запросом и таблицей на глаз не заметно. Так что считаю, что запросы тоже имеют право на жизнь - для тех пользователей у кого они не вызывают тормозов.

 

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

pyclient.zip

[vitan 2]

Роль клиента - забрать данные с сервера по HTTP, и записать в пользовательский источник данных. В 'config.ini' можно выбрать какой источник данных (frontend) вы хотите использовать: CSV или MS Access. Так как у нас нет ни даже заготовки общей БД, ни человека. который бы разбирался в этом, то сейчас 'pyclient' берет данные из аксесовской базы 'global.mdb'. И записывает в 'local.mdb' или 'local.csv'.

 

Между получением данных и их записью будет предусмотрена настраиваемая обработка. То есть из фиксированного набора полей, присылаемых с сервера вы сможете, например, удалить ненужные вам поля, добавить к полю "Voltage" букву "В", поменять запятые на точки, склеить два поля и т.д.

Думаю такой подход позволит так сказать расширить аудиторию =)

Верной дорогой идете, товарищи! :) Не зря столько времени потратили.

 

ЗЫ. Опять не открыть аксессовские файлы. Может, хоть в опенофис переведете?