jkrieger 0 20 октября, 2010 Опубликовано 20 октября, 2010 · Жалоба Ну что ж. Поигрался я с питоном и mdb. В принципе все достаточно просто. Ну и по ходу дела выяснилось, что и показывать то особо нечего =) То есть программка есть, работает. Но ее действия пока заключаются в перекидывании записей из одной БД в другую. Почему так попробую объяснить, чтобы всем было понятно. Немного теории MySQL, которая является де-факто стандартом на просторах рунета, это клиент-серверная СУБД. Она состоит из двух частей - серверной и клиентской. Серверная часть - это приложение, которое зпущено на сервере и слушает какой-либо порт. Клиент MySQL запускается на компьютере пользователя, подключается к этому порту и отправляет команды (запросы) серверной части, в ответ получает данные. Клиентом может служить, например консольное приложение mysql.exe, которое идет в поставке с MySQL Server, либо драйвер MyODBC, который можно скачать отдельно, или же какая-нибудь другая программа. Этот способ я называю прямым подключением к БД. На большинстве хостингов в целях безопасности запрещается подключаться к портам MySQL извне (то есть с наших с вами компьютеров), потому БД доступна только для приложений, запущенных на самом сервере. В таком случае для получения данных из БД обычно используют PHP-скрипты, к которым уже обращаются наши с вами браузеры. О проекте Теперь о настоящем. Раньше я уже говорил, что существуют хостинги, где прямое подключение разрешено, но там чаще всего необходимо указывать IP-адреса, с которых можно осуществлять такие подключения, а это согласитесь неудобно. Для каждого пользователя придется ручками лезть в настройки и добавлять его IP (пока я рассматриваю только бесплатные хостинги ;-) ). Потому я считаю, что удобнее и правильнее будет использовать python-клиента для импорта данных в нашу локальную БД. В результате схема будет примерно такая. В идеале Python-клиент будет показывать пользователю какие компоненты добавляются и что изменяется при каждом обновлении локальной БД. Но пока я не умею работать с GUI. Поэтому пример функционала будущей программы привожу в виде форм в Access'овской БД. В БД таблица Components, с которой будет работать САПР и hiddenComponents, скрытая сервисная таблица, туда моя программка добавляет новые компоненты. Чтобы увидеть новые компоненты нужно запустить форму newForm. Обновленные - modifiedForm. Кнопки к сожалению пока не работают. Прошу критиковать и предлагать изменения. noxious, как с вами связаться? Получилось ли у вас подключиться к БД на сервере? тау, скажите пожалуйста, при каком количестве компонентов начинают заметно проявляться тормоза с запросами? local.zip Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
тау 30 20 октября, 2010 Опубликовано 20 октября, 2010 (изменено) · Жалоба примерно до нескольких десятков компонентов тормозов не было даже при связи с базой на сервере в локальной сети (через промежуточный mdb файл содержащий запросы к основной БД) . Когда переключили на базу содержащую более 2000 компонентов и запросов стало около 50-60 (по количеству классов) так сразу и повылазило. в клиентских прогах (но не в Альтиуме) тормозов в локальной сети нет при общении с той же БД. Будете тестировать скорость - сразу проверяйте на пухлых таблицах. Для эксперимента сойдут даже искуственные таблицы , где размножить строки можно просто инкрементированием партнамбера. Изменено 20 октября, 2010 пользователем тау Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Uladzimir 96 20 октября, 2010 Опубликовано 20 октября, 2010 · Жалоба Ну. с началом. Пока все нормально. В соседней ветке Идет обсуждение Генератора Перечня от Брагина. Настоятельно рекомендую зайти к нему на сайт и скачать описаний к ГП. Там очень неплохо приведены необходимые параметры и порядок их заполнения. Не плохо бы их сразу иметь в базе, раз они застолбнены. Они хоть и переназначаемы, но лучше использовать как есть и с теми рекомендациями. примерно до нескольких десятков компонентов тормозов не было даже при связи с базой на сервере в локальной сети (через промежуточный mdb файл содержащий запросы к основной БД) . Когда переключили на базу содержащую более 2000 компонентов и запросов стало около 50-60 (по количеству классов) так сразу и повылазило. в клиентских прогах (но не в Альтиуме) тормозов в локальной сети нет при общении с той же БД. Будете тестировать скорость - сразу проверяйте на пухлых таблицах. Для эксперимента сойдут даже искуственные таблицы , где размножить строки можно просто инкрементированием партнамбера. Странно. Вод подключился к БД на HTTP и HTTPS Правда копии самих библиотек храню на локалке. Кроме новых конечно. База большая. Тормозов, кроме характерных для интернета-- никаких. Сами компоненты берет из локалки, если они там есть. Что и есть правильно. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
vitan 2 21 октября, 2010 Опубликовано 21 октября, 2010 · Жалоба В идеале Python-клиент будет показывать пользователю какие компоненты добавляются и что изменяется при каждом обновлении локальной БД. Охота пуще неволи. Ну зачем изобретать велосипед??? Почему нельзя использовать обычный diff, который уже есть в том же SVN и с его помощью все это узнавать? Только надо текстовые файлы генерить, вот и вся писанина. А тут на год работы себе придумали. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
тау 30 21 октября, 2010 Опубликовано 21 октября, 2010 · Жалоба Правда копии самих библиотек храню на локалке. Кроме новых конечно. База большая. Тормозов, кроме характерных для интернета-- никаких. Сами компоненты берет из локалки, если они там есть. Что и есть правильно. уточните пожалуйста смысл фразы "на локалке". С учетом того что Вы писали ранее "на локалке дома" , не подразумеваете ли под этим "на локальном компе" . Тогда конечно тормозов не будет. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Uladzimir 96 21 октября, 2010 Опубликовано 21 октября, 2010 · Жалоба не подразумеваете ли под этим "на локальном компе" . Тогда конечно тормозов не будет. Да так. Вечером сотру дома копию библиотек, попробую полностью через Интернет Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jkrieger 0 21 октября, 2010 Опубликовано 21 октября, 2010 · Жалоба Охота пуще неволи. Ну зачем изобретать велосипед??? Почему нельзя использовать обычный diff, который уже есть в том же SVN и с его помощью все это узнавать? Только надо текстовые файлы генерить, вот и вся писанина. А тут на год работы себе придумали. Немного непонял. Вы предлагаете все таки хранить данные в локальном источнике в виде текста? Но как их подключатьк САПР? И к "складу". Вобщем я решил, что пора уже начать хоть что-то пробовать. Владимир, расскажите пожалуйста как подключать Альтиум к БД по HTTP. Предлагаю не останавливать обсуждение и определиться теперь с классами (категориями) компонентов. Я попробовал привести свои библиотеки к тому, что мы тут обсуждаем, и даже у меня получилось более десятка классов. Будет ли удобным хранить их в разных таблицах? Может стоит как то придумать чтобы была одна таблица с компонентами, а из других к ним цеплялись различные данные из других таблиц в зависимости от класса? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
vitan 2 21 октября, 2010 Опубликовано 21 октября, 2010 · Жалоба Немного непонял. Вы предлагаете все таки хранить данные в локальном источнике в виде текста? Но как их подключатьк САПР? И к "складу". Вобщем я решил, что пора уже начать хоть что-то пробовать. Ну конечно! Неужели до сих пор я неясно выражался? Подключать к САПР через текстовый драйвер ODBC. Владимир, расскажите пожалуйста как подключать Альтиум к БД по HTTP. Да-да. Просим. И куда именно Вы подключаетесь? Может, и я смогу... Предлагаю не останавливать обсуждение и определиться теперь с классами (категориями) компонентов. Я попробовал привести свои библиотеки к тому, что мы тут обсуждаем, и даже у меня получилось более десятка классов. Завтра попробую скинуть то, что у меня сейчас есть. Около 50. Будет ли удобным хранить их в разных таблицах? Может стоит как то придумать чтобы была одна таблица с компонентами, а из других к ним цеплялись различные данные из других таблиц в зависимости от класса? О, да! :) Я с этого и начинал дискуссию... :) Считаю, что в общей БД надо хранить все компоненты в одной таблице, а локально создавать текстовые файлы. Один файл - одна библиотека. Как-то так. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
uriy 5 21 октября, 2010 Опубликовано 21 октября, 2010 · Жалоба Ну конечно! Неужели до сих пор я неясно выражался? Подключать к САПР через текстовый драйвер ODBC.Вероятно, это можно сделать в DbLib файле. Там есть radio button под названием Use connecting string, после этого становится активной кнопка Build. После нажатия кнопки открывается интересное окно, с заголовком "Свойства канала передачи данных" Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Uladzimir 96 21 октября, 2010 Опубликовано 21 октября, 2010 · Жалоба Владимир, расскажите пожалуйста как подключать Альтиум к БД по HTTP. Так указывается ссылка на базу в сетевом окружении Да-да. Просим. И куда именно Вы подключаетесь? Может, и я смогу... Нет. Это закрытый запаролленый ресурс Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jkrieger 0 21 октября, 2010 Опубликовано 21 октября, 2010 · Жалоба Так указывается ссылка на базу в сетевом окружении Но ведь сетевое окружение не использует HTTP, HTTPS. Охота пуще неволи. Ну зачем изобретать велосипед??? Почему нельзя использовать обычный diff, который уже есть в том же SVN и с его помощью все это узнавать? Только надо текстовые файлы генерить, вот и вся писанина. А тут на год работы себе придумали. Понимаете, хотелось сделать более наглядно. Хотя думаю будут возможны разные варианты. Считаю, что в общей БД надо хранить все компоненты в одной таблице, а локально создавать текстовые файлы. Виноват. Все стенялся поискать как подключаться к TXT через ODBC и попробовать. Оказывается очень даже неплохо, текстовая таблица из 2800 записей работала едва ли не быстрее чем с аццесом =) Правда без УГО и футпринтов пробовал. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Uladzimir 96 21 октября, 2010 Опубликовано 21 октября, 2010 · Жалоба Но ведь сетевое окружение не использует HTTP, HTTPS. Виноват. Все стенялся поискать как подключаться к TXT через ODBC и попробовать. Оказывается очень даже неплохо, текстовая таблица из 2800 записей работала едва ли не быстрее чем с аццесом =) Правда без УГО и футпринтов пробовал. подключены как сетевые диски Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Krys 2 22 октября, 2010 Опубликовано 22 октября, 2010 · Жалоба Вставлю свои 5 копеек: если подключение к инетовской базе будет происходить по какому-либо протоколу, отличному от http или https, то такие как я пользоваться этой базой не смогут вообще. Потому что у нас жёсткие ограничения по инету. В мир выход идёт через проксю, она рубит всё, кроме веб-страниц. И я уверен, что я такой не один. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
uriy 5 22 октября, 2010 Опубликовано 22 октября, 2010 · Жалоба Krys у нас на работе выходе тоже через прокси и он тоже все режет. Но я указал в винде в качестве шлюза адрес прокси сервера, во всех программах настройку прокси отрубил. Все отлично работает и ftp и svn. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Буратино 0 22 октября, 2010 Опубликовано 22 октября, 2010 (изменено) · Жалоба У АД серьезные проблемы с организацией доступа к базам данных, и я неоднократно акцентировал на этом внимание. Например, если источником данных на схеме является DBLib, с запросами в кач. виртуальных таблиц, то на этапе передачи информации с схемы на плату- возникают нереально дикие тормоза, с загрузкой проца на 100 процентов ! Для решения проблемы я вынужден сгружать инфу из запроса в таблицу и только потом могу перебросить схемотехнику в писиби. Без запросов (курсоров, виртуальных таблиц и т.п.) систему по управлению данными не построить, так как это основа реляционной модели хранения данных и доступа к ним. Так же не все ясно с процессом увязки посадочного места и УГО. Если после того, как на схему "стащить" компонент из DBLib, посмотреть его свойства, а именно его модельт футпринта, то можно столкнуться с ситуацией, когда АД НЕ находит футпринта в правильной библиотеке посадочных! Я также неоднократно подчеркивал это в своих постах, и даже просил потестить у себя эту ошибку/недоразумение. В результате я вынужден копировать свою библиотеку посадочных и указывать, для тех компонентов у которых почему-то нет связи, руками модель футпринта из этой библиотеки "зеркала". Что это за беда я не понимаю. Есть еще несколько моментов, но пока о них не буду говорить. Изменено 22 октября, 2010 пользователем Буратино Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
