[vitan 2]

А на чем основывается это утверждение? На общепринятом мнении что у МС все глюкаво? =)

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

Еще можно сказать, что в нем многого нет.

У нас использутеся MS SQL Server. В принципе, мне все равно, просто советую, не более.

 

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

Я не отчетливо понял смысл этого "локального" варианта. В предыдущих постах тоже. Можете описать поподробнее, чтобы дальше не возникало дурацких вопросов?

[jkrieger 0]

vitan, на данный момент принцип следующий.

 

В начале работы пользователь скачивает с SVN основную базу 'ACL.mdb' через TortoiseSVN. И отдельно скачивает (или создает) реплику этой базы (почему лучше скачивать, а не создавать расскажу позже, если мои догадки подтвердятся). В моем архиве она называется 'Реплика ACL.mdb'. Эта реплика для пользователя и будет рабочей. В ней пользователь может добавлять свои запросы/таблицы/формы, вобщем все что нужно для его лично работы. К ней и будет цепляться САПР. Туда же пользователь будет добавлять новые компоненты, с которыми сможет работать сразу же.

 

Добавление в общую базу, которая на SVN, будет производиться следующим образом. После того как пользователь добавил что то у себя в рабочей базе ('Реплика ACL.mdb'), он обновляет 'ACL.mdb' с SVN (вдруг она там уже успела измениться), и производит репликацию 'Реплика ACL.mdb' и 'ACL.mdb'. При этом все новые записи из первой будут добавлены во вторую и наоборот.

 

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

 

Ну и последним шагом - загрузка 'ACL.mdb' обратно на SVN .

 

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

Изменено 3 октября, 2010 пользователем Jack Krieger

[vitan 2]

Jack Krieger

Ага, дошло!

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

 

1. Чем по-Вашему такое хранение данных отличается от хранения их в простых файлах? Точнее, зачем Вам вообще аксесс, если Вы даже его данные дополнително отслеживате системой контроля версий? Почему не эксель, или текстовые файлы? Потому, что можно делать репликацию? Круг замкнулся.

 

Очевидно, Вы выбрали хранение данных под управлением СУБД потому, что СУБД обеспечивает нужные Вам функции. Это и многопользовательская работа, и транзакции, и SQL, и целостность данных, и т.п. Зачем же Вы от всего этого отказываетесь?

 

2. Как Вы видите себе работу нескольких пользователей? Допустим, я сделал все, как Вы описали, скачал базу, увидел там конденсатор, поправил в нем что-то, провел репликацию и зафиксировал изменения в SVN. Что увидит сосед, у которого прошлая версия конденсатора уже применена в десяти проектах? Что ему делать? Проводить репликацию с основной базой? Вы представляете его реакцию?

 

Я здесь пытаюсь сказать, что для нормальной коллективной работы потребуется специальная система управления процессами добавления компонентов в базу, их проверки, оповещения, и, может быть, чего-то еще. Это - целая отрасль в индустрии IT, в которой работает куча фирм, и они на этом зарабатывают. А Вы решили обойтись репликацией и вырваться вперед? :)

 

Вот, Вы сказали:

А вот механизм репликации баз мы точно напишем хуже чем МС. В этом я не сомневаюсь.

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

[Uladzimir 72]

Хоть вопросы не ком не но все же

1. Чем по-Вашему такое хранение данных отличается от хранения их в простых файлах?

Ничем. Оно именно такое

Точнее, зачем Вам вообще аксесс

Только для того, чтоб указать, где то что лежит, к чему можно добавить еще параметры

Почему не эксель

Можно и там, но там еще хуже

или текстовые файлы

Можно было бы, но их даже подключить к Altium проблематично

Очевидно, Вы выбрали хранение данных под управлением СУБД потому, что СУБД обеспечивает нужные Вам функции.

Ну не все, но хоть что-то

2.

Вы представляете его реакцию?

:maniac: Наверняка такая? :)

 

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

Это так.

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

[uriy 5]

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

AD жутко тормозит с экселем. Я начинал БД с экселя и перелез на Access

[jkrieger 0]

vitan, ответ прост и содержится в ваших словах:

 

...для нормальной коллективной работы потребуется специальная система управления процессами добавления компонентов в базу, их проверки, оповещения, и, может быть, чего-то еще. Это - целая отрасль в индустрии IT, в которой работает куча фирм, и они на этом зарабатывают. А Вы решили обойтись репликацией и вырваться вперед? :)

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

 

Не проще ли воспользоваться готовыми и бесплатными решениями (см. выше)?

Покажите пожалуйста готовое и бесплатное решение.

[vitan 2]

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

Воинствующие индивидуалисты-коллективисты? :) Люди - штуки социальные. :) Мы же на форуме не просто так оказались, верно?

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

Нужно доказывать, что косвенное воздействие тех вещей, на которые человек хочет забить, окажется очень сильным, и он рискует вечно повторять слова типа "ну почему у нас всегда все через ж...?".

 

AD жутко тормозит с экселем. Я начинал БД с экселя и перелез на Access

Это подозрительно. Если он работает через ODBC, то должно быть сопоставимо... По крайней мере, ментор особй разницы не чувствует...

 

Я нашел хоть как-то работающий механизм (а аццес удобнее всего из дву вариантов по умолчанию).

Ну, я же Вас не заставляю. Я просто даю замечание, что _по-моему_ это неправильно.

 

Покажите пожалуйста готовое и бесплатное решение.

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

 

А я не программист и у меня нет фирмы, которые это реализует.

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

[Krys 2]

Господа, одно наблюдение по полям:

Я тут все выходные пролазил по сайтам mouser.com и digikey.com. Хочу высказать пожелание, что с них нужно брать пример - насколько возможно. Другими словами, мне было бы очень приятно шариться по базе компонентов, если бы в ней были все те же колоночки - существенно упрощает жизнь разработчику. Я понимаю, что кому-то надо будет эти колоночки наполнять, и вряд ли кто-то этим будет заниматься специально. Но всё же. Стремиться к этому стОит. Вот пример:

Что я делаю на этих сайтах mouser.com и digikey.com? Провожу параметрический поиск нужных мне деталей. Вот нашёл я подходящие, вариантов несколько. Одни есть среди нарисованных компонентов, других нету. Какие я выберу? Конечно, которые уже нарисованы. А чтобы это проверить, я должен сначала произвести параметрический поиск в одном месте (на сайтах mouser.com и digikey.com), потом вручную залезть в базу АД, вбить название компонента и удостовериться, есть ли он или нет среди нарисованных компонентов. И все эти действия для каждой позиции я должен проделать вручную... И моё пожелание (возможно оно невыполнимо, но это пожелание, как было бы идеально) - чтобы имелась возможность параметрического поиска прямо по нашей базе АД не только по технологическим параметрам (название футпринта например), но и по электрическим. И не только по основным - типа проводимости pnp и npn, но и по таким узким, но полезным, типа допустимое напряжение, допустимый ток, пороговый уровень напряжения на затворе и т.д.... Пусть не для всех компонентов в начале это будет заполнено. Но будут и энтузиасты, которые будут по мере возможностей заполнять. Например, для тех, которые они сами у себя использовали. Ну или ещё как-то.

[vitan 2]

Что я делаю на этих сайтах mouser.com и digikey.com? Провожу параметрический поиск нужных мне деталей.

Именно! Это и есть то самое, ради чего база в первую очередь создается! Ведь все начинается с разработки. На этом этапе нужен именно параметрический поиск. А дальше - все по нарастайющей: и КД, и закупки и склад.

У меня сейчас более 50 библиотек. Практически все виды эл. компонентов. Это просто мечта! Не надо ничего искать и читать даташиты. Фильтр - и ты сразу видишь кандидатов. А уж потом читаешь даташит.

[Krys 2]

Полностью поддерживаю! А ещё бы это хорошо как-то состыковать с базой имеющихся на складе компонентов (которая обычно на многих предприятиях в виде 1С сделана и тому подобных программах).

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

 

... Во как мы размечтались! :))

[jkrieger 0]

И моё пожелание (возможно оно невыполнимо, но это пожелание, как было бы идеально) - чтобы имелась возможность параметрического поиска прямо по нашей базе АД не только по технологическим параметрам (название футпринта например), но и по электрическим. И не только по основным - типа проводимости pnp и npn, но и по таким узким, но полезным, типа допустимое напряжение, допустимый ток, пороговый уровень напряжения на затворе и т.д.... Пусть не для всех компонентов в начале это будет заполнено. Но будут и энтузиасты, которые будут по мере возможностей заполнять. Например, для тех, которые они сами у себя использовали. Ну или ещё как-то.

Тут я всеми руками "ЗА". И раньше пытался это выразить словами, но видимо плохо сформулировал =)

 

 

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

Возможно вы правы, я не знаком с этими системами. Поэтому прошу объяснить как это можно связать с САПР? Там можно создавать свои БД? Как доступ организован?

 

[Uladzimir 72]

mouser.com и digikey.com. Хочу высказать пожелание, что с них нужно брать пример - насколько возможно.

Ну так на примере digikey.com. я писал пример базы в 2008 году.

И сейчас использую.

И параметры оттуда через буфер переношу

Ну не руками же все вбивать :)

[vitan 2]

Я смотрю, оптимизма прибавилось. :)

Для подогрева вот скинул еще картинку с параметрическим поиском прямо в схемотехническом редакторе. На ней - поиск реизстора по парочке параметров и установка одного из подошедших кандидатов на схему (выделенный).

Это реальность! Надо только захотеть.

 

И параметры оттуда через буфер переношу

Ну не руками же все вбивать :)

Будьте осторожны! Я тут недавно выбирал что-то на сайте чип и дипа, так тоам была ошибка в значении какого-то параметра.

Это все к тому, что надо делать управление процессами проверки компонентов.

 

Поэтому прошу объяснить как это можно связать с САПР? Там можно создавать свои БД? Как доступ организован?

Ну, у меня связь пока только односторонняя. Т.е. невозможно увидеть в САПР те компоненты, которые не проверены этими средствами (юзаю первое). Но это совершенно не ограничивает применение. При желании сделать можно что угодно, ибо эти проги имеют такой же доступ к базе, как и альтиум. Вы можете _графически_ рисовать себе требуемый процесс хождения компонента по инстанциям, при этом выбор компонента будет производиться напрямую из базы (точнее, через то же ODBC). По окончании проверок прога сама может исполнить любой SQL-запрос, в т.ч. проставить то самое поле "проверено".

 

Да, и по поводу digikey. Брать пример можно, но не бездумно. Лично мне, например, не нравится у них отсутствие системности в классификации. Почему, к примеру, TVS-диоды внесены в категорию Circuit Protection, а не в Discrete Semiconductors? Потому, что классификация проведена сразу по нескольким признакам. Я считаю, что так делать нельзя. Если хотим делить по разным признакам, то надо делать _несколько разных_ классификаций, которые будут существовать параллельно. Пользователь сам выберет, какую он хочет в данный момент поюзать: ("диоды-резисторы-транзисторы" или "устройства защиты-усилители-и т.п."). Кончилась фантазия. :) Но здесь тоже надо внимательно обсудить.

__________2.rar

[jkrieger 0]

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

[Yuri Potapoff 0]

Это подозрительно. Если он работает через ODBC, то должно быть сопоставимо... По крайней мере, ментор особй разницы не чувствует...

 

Очень помогает отключить проверку антивирусами файлов определенного типа.

 

На счет тормозов Access при числе юзеров более 50 ничего не могу сказать, максимум что наблюдал 15 юзеров с непрерывными обращениями к базе (не альтиум). Замечал, что тормоза начинались при даже одной неправильно настроенной сетевой карте в одноранговой сети.