[Uladzimir 80]

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

Согласен

[jkrieger 0]

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

 

Направления мне видится два: добавлять через веб-интерфейс на сервере либо различными методами локально и при помощи pyclient передавать информацию на сервер.

 

В первом случае для добавления необходимо наличие интернета, что не есть хорошо, ну и весь этот интерфейс придется кому-то писать, хорошо, что не мне =)

 

Во-втором пользователь будет добавлять компонент себе в локальную БД, а потом pyclient должен будет вычитать новые записи и передать на сервер. Мне такой вариант нравится больше. Но тут возникают следующие сложности. Как показано в предыдущем моем посте пользователь может изменять поля в БД как ему удобно, и добавлять он будет для себя. И как автоматически привести эту информацию в соответствие с полями в общей БД я не знаю.

Тут можно предложить такие варианты:

 

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

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

 

2а. Добавлять компонент в локальную БД, структура которой повторяет общую. С тем чтобы после при помощи pyclient импортировать эти новые компоненты в рабочую БД как обычно, одновременно передав их на сервер.

2б. Добавлять компоненты при помощи клиента. Пользователь вводит информацию, pyclient изменяет и импортирует их в его рабочую БД, и одновременно передает их на сервер.

 

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

 

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

Для вас прикрепляю те же базы, но в формате 2000. Замените те что в архиве с программой. Скажите, у вас лицензионный Access 2000?

data.zip

[vitan 2]

Направления мне видится два: добавлять через веб-интерфейс на сервере либо различными методами локально и при помощи pyclient передавать информацию на сервер.

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

 

В первом случае для добавления необходимо наличие интернета, что не есть хорошо,

Довольно спорное утверждение.

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

 

 

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

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

 

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

Тут можно предложить такие варианты:

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

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

 

Последний вариант (2б) мне нравится больше всего, хоть для него и придется писать GUI.

ну и весь этот интерфейс придется кому-то писать, хорошо, что не мне =)

Дайте угадать! Вы просто не любите\не хотите заниматься веб-программированием, а предпочитаете "локальные GUI"? :)

 

Для вас прикрепляю те же базы, но в формате 2000. Замените те что в архиве с программой.

Спасибо.

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

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

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

 

Скажите, у вас лицензионный Access 2000?

Не-а. Не скажу. :)

[Uladzimir 80]

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

+1

[Буратино 0]

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

 

Вопрос не в том сколько времени открывается таблица/запрос, а в том сколько времени он тратит на формирование информации на этапе передачи схемы на плату! Работая с DBLib на основании запросов, проц загружается на 100 процентов и все виснет на 5 минут. Проверьте, ведь это концептуальное ограничение! В запросах вся суть реляционных БД .

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

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

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

[Uladzimir 80]

Не тратит нисколько,

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

[Буратино 0]

Не тратит нисколько,

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

 

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

Если таблицы, то список передаваемой на плату информации формируется быстро.

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

 

[vitan 2]

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

Мы так и хотим. А какие это другие проблемы?

 

Вопрос не в том сколько времени открывается таблица/запрос, а в том сколько времени он тратит на формирование информации на этапе передачи схемы на плату!

Опаньки! Не сразу дошло...

Получается, что альтиум коннектится к БД и на этапе рисования схемы, и на этапе передачи на разводку?

Что-то мне это не нравится... Если это так, то, получается, что я могу нарисовать схему, подождать месяц, начать разводить, а САПР полезет в базу? А если там уже все поменялось??

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

[Uladzimir 80]

Опаньки! Не сразу дошло...

Получается, что альтиум коннектится к БД и на этапе рисования схемы, и на этапе передачи на разводку?

Что-то мне это не нравится... Если это так, то, получается, что я могу нарисовать схему, подождать месяц, начать разводить, а САПР полезет в базу? А если там уже все поменялось??

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

Даю формально 2 раза.

Первый раз когда ставим УГО на схему.

Второй раз, когда она ставит Footprint на PCB

(Схема ни содержит информации о графике PCB)

И это во всех CAD так.

[vitan 2]

Второй раз, когда она ставит Footprint на PCB

(Схема ни содержит информации о графике PCB)

Что именно происходит во второй раз?

Я сколько ни видел САПРов, во всех в схеме указан тип корпуса.

[Uladzimir 80]

Да. Всхеме указаны ссылка на корпус. Здесь тоже самое.

Но самой графики нет.

Когда идет передача данных в PCB, пакет ищет Footprint, как указано в базе. Для этого ему нужно открыть в библиотеку на сервере и взять оттуда графику Footprint

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

Но боле правильно--- он должен лезть в общее хранилище и брать последнюю версию

[vitan 2]

Да. Всхеме указаны ссылка на корпус.

...

Когда идет передача данных в PCB, пакет ищет Footprint, как указано в базе.

...

Я вот это плохо понимаю.

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

Или Вы не так выразились?

[Uladzimir 80]

Он открывает футпринт, занесенный из базы в схему.

Тут опять терминология. Нет повторного обращения к таблице. Есть обращение только к хранилищу, где лежат Footprint.

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

[vitan 2]

Он открывает футпринт, занесенный из базы в схему.

Тут опять терминология.

Да нет, Владимир, тут не терминология, тут Ваша речь страдает. Я, если честно, вынужден по три раза перечитывать Ваши посты, чтобы понять их.

Ну вот скажите, как можно было иначе понять эту фразу?

Когда идет передача данных в PCB, пакет ищет Footprint, как указано в базе.

 

Следующие Ваши слова тоже не понятны.

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

Ну не понимаю я! :crying: Вы хотите спросить, где именно САПР должен искать посадочные места и как это увязать с работой с БД? Что именно я писал? Ткните ссылкой.

 

 

[Uladzimir 80]

тут Ваша речь страдает.

Что есть то есть. Аватор это подтверждает :)

как можно было иначе понять эту фразу

Ну будем так. Где-в сети лежит таблицы (или база) с параметрами и ссылками на УГО, Footprint (это что нужно для CAD) и прочим

Где то в сети, и скорее всего физически в другом мести хранятся сами библиотеки с этими УГО, Footprint.

Когда делается схема, по запросу али еще как автор получает из таблицы нужные параметры компонента, а также ссылку на УГО. Вставляет на схему. При этом УГО берется из сети.

адрес хранения УГО постоянный или динамический?

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

Говорю спасибо и не участвую в пополнении база.

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

 

Тоже поддерживаю. То есть скопом скопировать библиотекия в этом случае я не могу.

Выбирая по таблице компонент для вставки в схему, я его вижу графику УГО так как мне файл УГО подсовывает программа клиент. Она тут же может подсунуть и Footprint. Но формально пока мне он не нужен, а понадобится недели через 3. Поэтом забрать можно, но смысла нету.

Превосходно.Наконец схема есть готова.

Передаю изменения на схему.

Бац-- файла графики Footprint нету. Где взять. Ссылка в схеме есть. Но мне это ничего не дает, так как реально всете его нет, мне файл подсовывает клиент.

То есть AD опять должен лезть в сеть, слава богу ссылка на таблицу базы есть, и клиент уже подсовывает Footprint.

 

Если хранится на локалке УГО и Footprint-- проблем этих нету.

Если адрес хранилища УГО и Footprint известен -- тоже нету.

Но если файлы УГО и Footprint подсовывает программа клиент-- то есть всегда 2 обращения (для некоторых CAD 3)

1/ -- получение параметров и файла УГО

2. Получение файла Footprint