[jkrieger 0]

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

 

Немного теории

 

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

 

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

 

О проекте

 

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

Потому я считаю, что удобнее и правильнее будет использовать python-клиента для импорта данных в нашу локальную БД.

 

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

 

В идеале Python-клиент будет показывать пользователю какие компоненты добавляются и что изменяется при каждом обновлении локальной БД. Но пока я не умею работать с GUI. Поэтому пример функционала будущей программы привожу в виде форм в Access'овской БД. В БД таблица Components, с которой будет работать САПР и hiddenComponents, скрытая сервисная таблица, туда моя программка добавляет новые компоненты. Чтобы увидеть новые компоненты нужно запустить форму newForm. Обновленные - modifiedForm. Кнопки к сожалению пока не работают.

 

Прошу критиковать и предлагать изменения.

 

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

 

тау, скажите пожалуйста, при каком количестве компонентов начинают заметно проявляться тормоза с запросами?

local.zip

[тау 31]

примерно до нескольких десятков компонентов тормозов не было даже при связи с базой на сервере в локальной сети (через промежуточный mdb файл содержащий запросы к основной БД) . Когда переключили на базу содержащую более 2000 компонентов и запросов стало около 50-60 (по количеству классов) так сразу и повылазило.

в клиентских прогах (но не в Альтиуме) тормозов в локальной сети нет при общении с той же БД.

 

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

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

[Uladzimir 80]

Ну. с началом.

Пока все нормально.

В соседней ветке Идет обсуждение Генератора Перечня от Брагина.

Настоятельно рекомендую зайти к нему на сайт и скачать описаний к ГП.

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

Не плохо бы их сразу иметь в базе, раз они застолбнены.

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

 

примерно до нескольких десятков компонентов тормозов не было даже при связи с базой на сервере в локальной сети (через промежуточный mdb файл содержащий запросы к основной БД) . Когда переключили на базу содержащую более 2000 компонентов и запросов стало около 50-60 (по количеству классов) так сразу и повылазило.

в клиентских прогах (но не в Альтиуме) тормозов в локальной сети нет при общении с той же БД.

 

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

 

Странно. Вод подключился к БД на HTTP и HTTPS

Правда копии самих библиотек храню на локалке. Кроме новых конечно.

База большая. Тормозов, кроме характерных для интернета-- никаких. Сами компоненты берет из локалки, если они там есть. Что и есть правильно.

[vitan 2]

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

Охота пуще неволи. Ну зачем изобретать велосипед??? Почему нельзя использовать обычный diff, который уже есть в том же SVN и с его помощью все это узнавать? Только надо текстовые файлы генерить, вот и вся писанина. А тут на год работы себе придумали.

[тау 31]

Правда копии самих библиотек храню на локалке. Кроме новых конечно.

База большая. Тормозов, кроме характерных для интернета-- никаких. Сами компоненты берет из локалки, если они там есть. Что и есть правильно.

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

[Uladzimir 80]

не подразумеваете ли под этим "на локальном компе" . Тогда конечно тормозов не будет.

 

Да так.

Вечером сотру дома копию библиотек, попробую полностью через Интернет

[jkrieger 0]

Охота пуще неволи. Ну зачем изобретать велосипед??? Почему нельзя использовать обычный diff, который уже есть в том же SVN и с его помощью все это узнавать? Только надо текстовые файлы генерить, вот и вся писанина. А тут на год работы себе придумали.

Немного непонял. Вы предлагаете все таки хранить данные в локальном источнике в виде текста? Но как их подключатьк САПР? И к "складу". Вобщем я решил, что пора уже начать хоть что-то пробовать.

 

Владимир, расскажите пожалуйста как подключать Альтиум к БД по HTTP.

 

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

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

 

[vitan 2]

Немного непонял. Вы предлагаете все таки хранить данные в локальном источнике в виде текста? Но как их подключатьк САПР? И к "складу". Вобщем я решил, что пора уже начать хоть что-то пробовать.

Ну конечно! Неужели до сих пор я неясно выражался? Подключать к САПР через текстовый драйвер ODBC.

 

Владимир, расскажите пожалуйста как подключать Альтиум к БД по HTTP.

Да-да. Просим. И куда именно Вы подключаетесь? Может, и я смогу...

 

 

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

Завтра попробую скинуть то, что у меня сейчас есть. Около 50.

 

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

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

[uriy 5]

Ну конечно! Неужели до сих пор я неясно выражался? Подключать к САПР через текстовый драйвер ODBC.

Вероятно, это можно сделать в DbLib файле. Там есть radio button под названием Use connecting string, после этого становится активной кнопка Build. После нажатия кнопки открывается интересное окно, с заголовком "Свойства канала передачи данных"

[Uladzimir 80]

Владимир, расскажите пожалуйста как подключать Альтиум к БД по HTTP.

 

Так указывается ссылка на базу в сетевом окружении

 

Да-да. Просим. И куда именно Вы подключаетесь? Может, и я смогу...

Нет. Это закрытый запаролленый ресурс

[jkrieger 0]

Так указывается ссылка на базу в сетевом окружении

Но ведь сетевое окружение не использует HTTP, HTTPS.

 

Охота пуще неволи. Ну зачем изобретать велосипед??? Почему нельзя использовать обычный diff, который уже есть в том же SVN и с его помощью все это узнавать? Только надо текстовые файлы генерить, вот и вся писанина. А тут на год работы себе придумали.

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

 

Считаю, что в общей БД надо хранить все компоненты в одной таблице, а локально создавать текстовые файлы.

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

 

[Uladzimir 80]

Но ведь сетевое окружение не использует HTTP, HTTPS.

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

подключены как сетевые диски

[Krys 2]

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

[uriy 5]

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

[Буратино 0]

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

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

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

 

Так же не все ясно с процессом увязки посадочного места и УГО. Если после того, как на схему "стащить" компонент из DBLib, посмотреть его свойства, а именно его модельт футпринта, то можно столкнуться с ситуацией, когда АД НЕ находит футпринта в правильной библиотеке посадочных! Я также неоднократно подчеркивал это в своих постах, и даже просил потестить у себя эту ошибку/недоразумение. В результате я вынужден копировать свою библиотеку посадочных и указывать, для тех компонентов у которых почему-то нет связи, руками модель футпринта из этой библиотеки "зеркала". Что это за беда я не понимаю.

 

Есть еще несколько моментов, но пока о них не буду говорить.

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