[vitan 2]

Понимаете, хотелось сделать более наглядно. Хотя думаю будут возможны разные варианты.

Понимаю, потому и советую сразу использовать стандартные решения типа diff. Куда уж более наглядно, и отработано годами.

 

Виноват. Все стенялся поискать как подключаться к TXT через ODBC и попробовать. Оказывается очень даже неплохо, текстовая таблица из 2800 записей работала едва ли не быстрее чем с аццесом =) Правда без УГО и футпринтов пробовал.

Ну вот и хорошо. А УГО и футпринты все равно ведь не в этих файлах будут, и вообще не в БД, поэтому от них ничего не зависит.

 

Вставлю свои 5 копеек: если подключение к инетовской базе будет происходить по какому-либо протоколу, отличному от http или https, то такие как я пользоваться этой базой не смогут вообще. Потому что у нас жёсткие ограничения по инету. В мир выход идёт через проксю, она рубит всё, кроме веб-страниц. И я уверен, что я такой не один.

У меня вообще все отключено кроме POP3 и SMTP. Но от этого концепция не должна страдать.

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

 

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

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

А вот и построим! Основная идея, повторюсь, в том, чтобы создавать для пользователей текстовые файлы с компонентами. Сама БД будет организована нормально, в полном соответствии с теорией. Там будут запросы, таблицы, связи, контроль целостности и т.п. Но для ползователей (некоторых, типа альтиумовцев) с помощью какого-нибудь генератора будут создаваться текстовые файлики с компонентами, которые он будет скачивать себе и пользоваться на здоровье.

 

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

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

 

 

 

[Uladzimir 96]

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

Ну понятно.

В той или иной мере и я так раскладываю.

[jkrieger 0]

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

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

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

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

 

vitan, а не подскажете, можно ли в текстовых БД задать два ключевых поля? Бо проверять вручную (программно) существование каждого элемента не очень хочется.

Да и по применению diff. Это ж надо будет держать две копии БД: одна с которой будет работать САПР а другая обновляться клиентом. После обновления - diff. Правильно?

 

P.S.: Шальная мысль... А может ну его все эти БД? Залить на SVN этот текстовый файл вместе с футпринтами и УГО и обновлять его тем же TortoiseSVN? Основная ветка закрыта для коммита пользователей, добавляем в соседние. По мере надобности делаем merge в основную...

[vitan 2]

vitan, а не подскажете, можно ли в текстовых БД задать два ключевых поля? Бо проверять вручную (программно) существование каждого элемента не очень хочется.

Что такое "текстовая БД"? :) Зачем Вам там ключевые поля? Уж не для связи ли таблиц между собой? :)

Забудьте. Это не БД, а просто _источник данных_.

 

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

 

Да и по применению diff. Это ж надо будет держать две копии БД: одна с которой будет работать САПР а другая обновляться клиентом. После обновления - diff. Правильно?

Да, но не совсем.

Если планируется использовать в качестве транспорта SVN, то может получится, что после обновления diff применять уже будет бессмысленно. Это будет тогда, когда юзер ничего не трогал в локальном файле, а на сервере появилась новая версия. При обновлении SVN просто потрет старую и все. Юзер сможет узнать об изменениях только обратившись к серверу средствами SVN, извлекши две версии файла, и сравнив их между собой, пользуясь средствами того же SVN.

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

А на сервере файлы должны появляться автоматически после изменений в БД. Запускать триггер, который будет обновлять эти файлы и коммитить в SVN. И всего делов. А юзеры обновляют когда хотят.

 

P.S.: Шальная мысль... А может ну его все эти БД? Залить на SVN этот текстовый файл вместе с футпринтами и УГО и обновлять его тем же TortoiseSVN? Основная ветка закрыта для коммита пользователей, добавляем в соседние. По мере надобности делаем merge в основную...

Дык не вопрос! :) Только тогда забудьте про целостность данных, запросы типа "вывести все проверенные резисторы Bourns 0603 с номиналом от 0 до 1 кОм, поставляемые фирмой "Рога и Копыта" для двух предыдущих моих изделий". И т.п.

Обо всем этом я уже много раз говорил...

[jkrieger 0]

Что такое "текстовая БД"? :) Зачем Вам там ключевые поля?

Вообще-то для уникальности компонентов =)

 

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

Никаких. И насколько я понял Microsoft ODBC Text Driver этого не позволит сделать. Да и вообще генерация текстовых файлов считаю не очень удачно. Пока будет mdb. Позже надеюсь добавить другие СУБД.

 

При обновлении SVN просто потрет старую и все. Юзер сможет узнать об изменениях только обратившись к серверу средствами SVN, извлекши две версии файла, и сравнив их между собой, пользуясь средствами того же SVN.

Вроде как SVN никогда не трет "просто". Оно импортирует изменения. Ну это не важно.

 

А на сервере файлы должны появляться автоматически после изменений в БД. Запускать триггер, который будет обновлять эти файлы и коммитить в SVN. И всего делов. А юзеры обновляют когда хотят.

Тут минус. Нужно на сервере иметь SVN-клиент. Есть ли такие на PHP или Pure Python я не знаю. Иначе потребуется выделенный сервер.

Ну и далее:

Дык не вопрос! :) Только тогда забудьте про целостность данных, запросы типа "вывести все проверенные резисторы Bourns 0603 с номиналом от 0 до 1 кОм, поставляемые фирмой "Рога и Копыта" для двух предыдущих моих изделий". И т.п.

Обо всем этом я уже много раз говорил...

Разве это не минус? Или вы хотите, чтобы ользователь после апдейта и диффа импортировал еще этот текстовый файл себе в СУБД?

 

По классам. Вот у вас например для LED и Shottky набор параметров (полей в БД) разный? Или одинаков для всех Diodes?

[Uladzimir 96]

Вообще-то для уникальности компонентов =)

Если генерируется из базы с ключевым полем-- уникальность должна уже обеспечиваться

Цитата(vitan @ Oct 22 2010, 20:03) Вот, как организовать текстовые файлы, чтобы в них отражалось несколько библиотек компонентов - это хороший вопрос. Предлагаю на нем и сосредоточиться. Я тут выше сказал про "один файл - одна библиотека", но как-то мне самому это не очень... Есть мысли?

Никаких.

Алтиум найдет. Главное уникальность имен УГО и Footprint

По классам. Вот у вас например для LED и Shottky набор параметров (полей в БД) разный? Или одинаков для всех Diodes?

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

Так уж точно должны отличаться :)

[vitan 2]

Если генерируется из базы с ключевым полем-- уникальность должна уже обеспечиваться

Так точно.

 

Никаких. И насколько я понял Microsoft ODBC Text Driver этого не позволит сделать.

Так ведь дело не в драйвере, а в том, как мы организуем данные.

 

Да и вообще генерация текстовых файлов считаю не очень удачно.

Таки почему?

 

Тут минус. Нужно на сервере иметь SVN-клиент. Есть ли такие на PHP или Pure Python я не знаю. Иначе потребуется выделенный сервер.

Не обязательно иметь клиента SVN на сервере. Он может быть где угодно. Главное - сделать механизм автоматического запуска этого клиента, чтобы он коммитил изменения.

 

Разве это не минус? Или вы хотите, чтобы ользователь после апдейта и диффа импортировал еще этот текстовый файл себе в СУБД?

Где именно Вы увидели минус?

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

 

По классам. Вот у вас например для LED и Shottky набор параметров (полей в БД) разный? Или одинаков для всех Diodes?

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

Так уж точно должны отличаться :)

LED и Sottky находятся на одном уровне дерева, поэтому у них _может_ быть разный набор параметров. В данном случае параметры разные. Но есть общие параметры, унаследованные от DIODES.

[Uladzimir 96]

Так точно.

...

Где именно Вы увидели минус?

...

LED и Sottky находятся на одном уровне дерева, поэтому у них _может_ быть разный набор параметров. В данном случае параметры разные. Но есть общие параметры, унаследованные от DIODES.

1 мы думаем одинаково :)

2 Я тоже не вижу минуса

3. То есть вы предлагаете добавлять более общим параметрам а толстых ветках дерева, параметры дополнительные (для тонких веток дерева)?

Мне это тоже импонирует.

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

[vitan 2]

3. То есть вы предлагаете добавлять более общим параметрам а толстых ветках дерева, параметры дополнительные (для тонких веток дерева)?

Мне это тоже импонирует.

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

О, да. Я уже говоил, пришлось попариться недели две. Поэтому и выложил, для дальнейшего усовершенствования. Есть вопросы именно по выложенному?

 

[Uladzimir 96]

Ни каких. Одобрямс. :)

По поводу новых побегов дерева по мере необходимости.

Соответственно по уровню вложенности- тоже.

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

Но я думаю это это не страшно.

Так, например, сборка из 8 диодов в 6 выводном корпусе Dalc208 можно отнести к

1. Diodes/Bridge

2/ Diodes/Array

1/IC/

 

В общем как в каталогах.

 

Порой находишь интересные вещи там, где даже б не подумал :(

[vitan 2]

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

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

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

[Uladzimir 96]

Ну и я о том же.

Они существуют в разных ветках. Могут и возможно должны иметь одно название в базе.

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

В принципе тут страшного ничего нет.

[vitan 2]

Так, например, сборка из 8 диодов в 6 выводном корпусе Dalc208 можно отнести к

1. Diodes/Bridge

2/ Diodes/Array

1/IC/

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

Суть в том, что приведенная мной классификация на самом деле рассчитана на понимание того, какие параметры являются характерными для каждой группы компонентов. Т.е. фактически деление происходит именно по набору параметров, и каждый набор получает свое имя (в виде названия ветки) и расположение (в виде места в дереве). Поэтому перед тем, как положить куда-то новый компонент, я всегда смотрю, какие параметры у него наиболее важны. Понятно, что эта сборка может быть рассмотрена и как IC, и как Bridge. Но кто ее будет использовать в качестве моста, например? Это надуманно, так же, как и микросхема.

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

Но, подумать, конечно, не мешает. Разные классификации, по-моему, это выход. Главное, четко продумать принципы, по которым будет строиться вторая, третья и т.п. классификации. Есть предложения?

[jkrieger 0]

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

 

Да и вообще, хотелось бы чтобы добавление компонентов производилось в локальную копию. И потом отправлялись каким-либо образом в "базу-песочницу" на сервере.

[vitan 2]

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

 

Да и вообще, хотелось бы чтобы добавление компонентов производилось в локальную копию. И потом отправлялись каким-либо образом в "базу-песочницу" на сервере.

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

 

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

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

 

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