[Uladzimir 90]

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

Значит они вносить изменения не могут.

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

Значит все таки есть круг, кому доступ не только для чтения.

 

 

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

Ну и хозяин-- тот, у кого все это хранится.

 

Что я не так понимаю?

 

[vitan 2]

Что я не так понимаю?

Все Вы правильно поняли. :)

 

Я для себя из дискуссии все-таки вынес немного полезного, за что все участникам спасибо.

Постараюсь подытожить, описать видение концепции сверху, так сказать. Надеюсь, это будет взято энтузиастами как руководство к действию.

 

1 Есть сервер в интернете - для общей БД

1.1 На сервере установлена СУБД (не аксес)

1.2 На нем же установлен веб-сервер

1.3 На нем же установлен интерпретатор PHP или аналогичный

1.4 На одной из страниц веб-сервера доступен веб-клиент к БД, которая под управлением СУБД

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

 

2 Доступ схемотехников (юзеров) к БД из САПР

2.1 БД не привязана к какому-либо САПР

2.2 Источником данных для САПР является либо непосредственно сервер, либо специально обновляемый локальный источник

2.3 Компоненты группируются в библиотеки компонентов по некоторым признакам (очевидно, тип)

2.4 При прямом соединении с сервером содержимое библиотек компонентов попадает в САПР путем исполнения запросов, хранящихся на сервере

2.5 При обращении САПР к локальному источнику данных она получает содержимое библиотек компонентов из таблиц (запросов) локального источника. Для простоты генерации предлагаю использовать в качестве локального источника текстовые файлы с разделителями-запятыми.

 

3 Веб-клиент

3.1 Он позволяет проводить необходимые операции со всеми сущностями в БД.

 

4 Организация БД

4.1 Данные, требующие подготовки (преобразования) для определенной САПР, подготавливаются (преобразуются в необходимый вид) средствами сервера. Для выбора типа САПР предусматривается указание, с каким САПР хочет работать пользователь.

4.2 Алгоритм генерации локального источника не зависит от выбранного типа САПР, т.к. берет уже подготовленную сервером информацию.

4.3 В БД имеются справочники (таблицы) для следующих сущностей:

4.3.1 Электронные компоненты

4.3.2 Конструктивные (топологические) элементы

4.3.3 Библиотеки компонентов

4.3.4 Библиотеки УГО

и т.п.

 

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

Кстати, здесь очень поможет SVN или CVS (если источник будет в виде текста) - сразу обнаружатся изменения. Коммиты локального источника отключить.

 

По-моему, неплохо. Вроде, все задачи решены?

[Krys 2]

По-моему, неплохо. Вроде, все задачи решены?

Даже мне стало понятно :)

 

некоторые корректировки дополнения и вопросы от меня косательно системы в общем=)

doc

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

А сами документы предлагалось выкладывать в другом месте (Владимир завёл хранилище, см. выше).

[Uladzimir 90]

2.3 Компоненты группируются в библиотеки компонентов по некоторым признакам (очевидно, тип)

 

По-моему, неплохо. Вроде, все задачи решены?

По всем пункиам +

Этот просто уточнение. Нужна групповка для графических изображений (УГО и FOOTPRINT) по типам САПР

Ментор на прямую не поймет библы для Altium и на оборот.

[vitan 2]

По всем пункиам +

Ура.

 

Этот просто уточнение. Нужна групповка для графических изображений (УГО и FOOTPRINT) по типам САПР

Ментор на прямую не поймет библы для Altium и на оборот.

Уточню уточнение. :)

Нужна не группировка по УГО и футпринтам по типам САПР, нужно создать разные правила для формирования конечных результатов для каждого САПР, и выполнять подготовку данных по этим правилам программно средствами сервера, предварительно указав, с каким САПР мы работаем. Это уже написано в п. 4.1.

 

Группировка УГО и футпринтов должна быть сделана внутри БД по другим признакам.

Я всегда предлагал группировать УГО по первым буквам префикса рефдеса (типы брать из ГОСТа). А футпринты группировать по первым буквам IPC7351, но Вы предложили брать структуру библиотек футпринтов из калькулятора.

Я тогда согласился, а сейчас еще раз посмотрел на него, и вижу, что в ней тоже не хватает системности. Вот, к примеру, рядом лежат библиотеки TH и СONNECTORS. Ну это же отстой. Путаница только возникает.

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

Что скажете?

 

 

[Uladzimir 90]

Нужна не группировка по УГО и футпринтам по типам САПР

Я имел ввиду только систематизацию мест хранения. Это ведь тоже попадпет под определение "групповка"?

Я всегда предлагал группировать УГО по первым буквам префикса рефдеса (типы брать из ГОСТа).

Согласен, но есть существенный недостаток. Оно не совпадает с буржуйским.

Я бы вел обе системы

А футпринты группировать по первым буквам IPC7351, но Вы предложили брать структуру библиотек футпринтов из калькулятора.

Я тогда согласился, а сейчас еще раз посмотрел на него, и вижу, что в ней тоже не хватает системности. Вот, к примеру, рядом лежат библиотеки TH и СONNECTORS. Ну это же отстой. Путаница только возникает.

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

Что скажете?

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

По коннекторам-- это зверинец. который сложно засистематизировать.

В части таких зверинцев я тоже использую иную классификацию.

Но основа остается основой. первые буквы ТИПОВЫХ Footprint по IPC7351 вполне ложаться в квалификацию по первым буквам.

О зверинце соединителей и прочей экзотики-- нужно думать.

У меня всегда проблемы BH10 это 1.73456.. по Harting, или что это. Тоже касается карточек. PCI и прочей типоразмерной заготовки

[vitan 2]

Я бы вел обе системы

А разве есть буржуйская система? Не встречал. Приведите пример.

 

О зверинце соединителей и прочей экзотики-- нужно думать.

Да, здесь есть проблемы. Я вот, ввел класс "CONN", которого нет в IPC, и складываю туда все подряд: HARTING_..., MOLEX_...

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

 

[Uladzimir 90]

А разве есть буржуйская система? Не встречал. Приведите пример.

 

 

Да, здесь есть проблемы. Я вот, ввел класс "CONN", которого нет в IPC, и складываю туда все подряд: HARTING_..., MOLEX_...

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

 

Ну у них обозначается "U", то , что в ГОСТ "D". И так далее

класс "CONN" у меня примерно также. Только туда соединители и складываю

А для всего подряд== класс "Other" :)

 

Но вообще предлагаю иметь и класс "Unsorting"

[jkrieger 0]

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

У меня же просто отсутствует это промежуточное звено в виде аксесса. Как-то так получается. :)

Аццесс на сервере наверное и не получится. Аццесс вроде как файлоориентированная СУБД. Да и локально не обязательно именно mdb генерировать. Просто нам альтиумщикам оно сподручней. В качестве локальной БД можно будет и SQL Server и MySQL и что угодно, главное чтобы я нашел библиотеки для работы с ними под питон. Код от этого не сильно изменится.

 

Хотя, вот, подумал немного, и понял, что это выльется в сложности для САПРонезависимости. Вы же все преобразования данных будете делать на питоне и подгонять MDB под альтиум, так ведь? Т.о. для коннекта к БД из другой САПР нужно будет писать новую программу (на питоне уже вряд ли, ибо это будете уже не Вы :) ). Может, все-таки для преобразования данных будете использовать программинг на сервере, средствами СУБД? Это поможет хотя бы как-то унифицировать код, необходимый для разных САПР. Да и генерилка для аксесса будет одна для всех САПР.

Как думаете?

Пока сложно сказать с какими трудностями придется столкнуться. Но в идеале я вижу так: прислал мне сервер данные о компонентах (наименование, производитель. наименование УГО, футпринты и все все параметры которые к нему относятся). Я беру один, смотрю к какой группе он относится. Допустим резистор, и тогда я выполняю SQL запрос на добавление этого компонента в таблицу резисторов в локальной БД. Потом следующий... и т.д. Сам запрос будет где-нить в файлике текстовом храниться, и при желании пользователь сможет заточить его под себя.

Для начала я попробую сделать это для Access или SQLite (с SQLite я уже работал). Потом можно добавим поддержку других СУБД.

 

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

Кстати, здесь очень поможет SVN или CVS (если источник будет в виде текста) - сразу обнаружатся изменения. Коммиты локального источника отключить.

 

По-моему, неплохо. Вроде, все задачи решены?

Хех, думаю у нас впереди еще много сломанных копий. Но направление мы кажется выбрали =)

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

 

А сами документы предлагалось выкладывать в другом месте (Владимир завёл хранилище, см. выше).

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

Это правда удобно =)

 

 

[Uladzimir 90]

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

Это правда удобно =)

Это не навязывание, а подсказка.

Я забыл про этот ресурс.

Принято

[vitan 2]

Да и локально не обязательно именно mdb генерировать. Просто нам альтиумщикам оно сподручней. В качестве локальной БД можно будет и SQL Server и MySQL и что угодно, главное чтобы я нашел библиотеки для работы с ними под питон. Код от этого не сильно изменится.

Очень Вам советую текстовые файлы. Из них любой первоклассник всегда сделает себе любой аксес, эксель, SQL и еще черта в ступе. И человеку понятно и контролю версий (diff работать будет, а это великая вещь).

 

Но в идеале я вижу так: прислал мне сервер данные о компонентах (наименование, производитель. наименование УГО, футпринты и все все параметры которые к нему относятся). Я беру один, смотрю к какой группе он относится. Допустим резистор, и тогда я выполняю SQL запрос на добавление этого компонента в таблицу резисторов в локальной БД. Потом следующий... и т.д.

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

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

 

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

Ну да, появляется гибкость. Но опять же, надо будет обязательно отключить запись. А то какой-нибудь пользователь заточит под себя DROP TABLE...

 

Для начала я попробую сделать это для Access или SQLite (с SQLite я уже работал). Потом можно добавим поддержку других СУБД.

Начните с текста. Уверен, многие скажут спасибо.

[jkrieger 0]

Ну да, появляется гибкость. Но опять же, надо будет обязательно отключить запись. А то какой-нибудь пользователь заточит под себя DROP TABLE...

Ну и что? Он же так убьет свою локальную базу. Какое дело остальным до этого? С сервера пользователи будут получать данные в одностороннем порядке.

 

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

[vitan 2]

Ну и что?

Да это я все про общую БД говорю, не про локальную. Чтоб не забыть типа... :) Ну, давайте, посмотрим, что получится.

 

UPD.

Спросонья понял-таки, почему я зацепился за вариант с питоновской программой. :) Точнее, против него.

С ним мы рискуем похоронить прямое соединение САПР с интернетовской базой. В ней ведь данные останутся неподготовленными и САПР не поймет, к примеру, списки УГО. Просто никто не будет к ней соединяться.

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

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

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

[jkrieger 0]

UPD.

Спросонья понял-таки, почему я зацепился за вариант с питоновской программой. :) Точнее, против него.

С ним мы рискуем похоронить прямое соединение САПР с интернетовской базой. В ней ведь данные останутся неподготовленными и САПР не поймет, к примеру, списки УГО. Просто никто не будет к ней соединяться.

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

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

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

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

С другой стороны при каждом запуске САПР выполняет запрос SELECT * FROM ComponentsTable, и придется каждый раз передавать большой объем данных.

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

 

Кстати, перечитал ваш давнешний пост, обратил внимание на эту фразу.

...рассказать, как это реализовано у меня. У меня есть сервер, и я там админ. САПР коннектится через HTTP (в состав САПР входит спец. комплекс софта, который обеспечивает предоставление данных по HTTP от ODBC) к ODBC; тот, в свою очередь, к БД. Имея HTTP, клиент не знает, где физически находится БД (для ODBC нужно указывать физическое расположение, как известно).

Я конечно могу путаться в терминах, но вроде бы Альтиум не может подключаться через HTTP (или придется писать свой софт, а я не смогу - понимаю принципов работы). Все что доступно нам альтиумщикам вот на картинке. Может потому мне немного не понятно как можно и напрямую запросы не слать и тем не менее работать из сапр прямо с общей БД?

[vitan 2]

С другой стороны при каждом запуске САПР выполняет запрос SELECT * FROM ComponentsTable, и придется каждый раз передавать большой объем данных.

Опять же, смотря какой САПР. Вот тау сказал, что для альтиума это проблема, но и то не потому, что сама библиотека большая, а потому, что альтиум выдает кучу запросов. Остальные САПРы этим не страдают. В каждой библиотеке будет не так и много компонентов. Вот у меня, например, самая густонаселенная библиотека - это конденсаторы керамические, но и то в ней не больше 100 штук. Ну да, есть секундная пауза при открытии в САПР, но она примерно одинакова у меня для всех библиотек, даже для маленьких. Вопросы быстродействия и оптимизации - это, согласитесь, надо оставлять на потом, главное сразу не выбрать неправильный путь, не более.

 

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

Да, конечно. Прямое соединение с возможностью записи надо отключать всеми возможными мерами.

 

 

Кстати, перечитал ваш давнешний пост, обратил внимание на эту фразу.

 

Я конечно могу путаться в терминах, но вроде бы Альтиум не может подключаться через HTTP (или придется писать свой софт, а я не смогу - понимаю принципов работы). Все что доступно нам альтиумщикам вот на картинке. Может потому мне немного не понятно как можно и напрямую запросы не слать и тем не менее работать из сапр прямо с общей БД?

Ясно. Попробую разъяснить.

Запросы шлются моим САПРом к моему веб-серверу. Это только запросы SELECT, не более. Других САПР, слава Богу, не выдает. Эти запросы идут на сервер. Там стоит IIS (веб-сервер, аналог Apache, ну, понятно). На веб-сервере есть спец. DLL, которая имеет возможность связываться с драйвером ODBC. ODBC подключено, понятно, к БД. DLL может выдавать результаты SELECT-ов, которые к ней поступают по протоколу HTTP (ибо она на веб-сервере). Выдает она их обратно запросившему, т.е. САПРу по тому же HTTP. САПР отображает данные юзеру.

Этот механизм позволяет доибться того, чего надо: юзеры подключены к БД на сервере, но не напрямую, а через посредника (DLL), который скрывает истинное местонахождение БД от юзера. Юзер просто указывает в настройках веб-ссылку на веб-сервере, куда ему надо коннектиться. Общение между посредником и юзером идет по стандартному протоколу HTTP. Т.е. в рамках этого протокола клиент (САПР) и сервер (DLL) передают друг другу и SELECT, и его результаты. Как они там это отформатировали, какие там посылки, кадры, формат я тоже не знаю, да и знать не хочу. Мне важно, что цель достигнута.

Теперь про альтиум и другие.

Очевидно, Вам надо найти в альтиуме подобный механизм.

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

Про запросы напрямую. Еще раз повторю, что "напрямую" - это значит "зная физическое расположение БД". И плюс - по записи, не более.