[Uladzimir 90]

А поиск от выбора чем отличается?

 

Поиск-- ограничение списка компонентов па отдельным параметрам.

Выбор-- анализ компонентов на применимость в конкретной ситуации.

 

Нет. я не против.

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

Просто, что важно для микросхемы-- не важно для конденсатора.

И таких разношерстных компонентов -- миллион.

Нельзя доводить до абсурда и иметь миллион параметров

[vitan 2]

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

Неужели это главная трудность?

Тут уже выше говорили, что найти сейчас место в интернете гораздо проще, чем что-то хорошее написать. Я с этим согласен. В конце-концов, можно поставить сервер у себя дома. У меня, например, на домашнем компе внешний IP. Организуете бесплатный DNS и вперед. Можете и сами себе подключить внешний IP, полезно.

Но, это - если это главная причина.

 

Со стороны пользователей необходимо некоторое клиентское ПО (будут это Workflow системы, или самописный клиент, думаю не имеет особого значения).

Да, чуть не забыл! Можно же написать клиент с веб-интерфейсом (веб-клиент), разместить его на том же сервере и забыть про проблемы. Мы это как раз осваиваем сейчас.

 

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

Ой! Это уже даже не клиент, а какой-то супервизор для репликации. Что-то мне крайне смнительным кажется такой путь...

 

Причем не так, как это сделано в Access - все самое свежее в базу, а с подтверждением каждого изменения.

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

Вы уверены?

 

Кстати, по количеству отказов можно считать рейтинг.

Отрицательная логика? :)

 

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

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

Да. В этом Вам мало кто поможет.

 

А пока предлагаю тренироваться и оттачивать работу по схеме с SVN, Access и репликацией =)

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

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

В общем, подумайте.

 

P.S. С SVN тоже оказывается не все гладко.

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

 

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

А что мешает выделить число в PDF и нажать Ctrl+C и Ctrl+V?

 

На счет там пишут параметры с min, typ, max значениями.. Может хорошо, но этого мало. Графиков в таблицу не введешь. Такие данные только для поиска годятся, но не для выбора компонента

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

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

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

 

А поиск от выбора чем отличается? Если бы были хотябы численные значения, без графиков - это бы уже облегчило жизнь. Был бы аналог того, что реализовано в digikey.com и им подобным. Можно было бы выбрать хоть как-то подходящие. А потом уже на них почитать дадащиты и сделать окончательный выбор. Естественно, этот параметрический поиск по базам не должен заменять чтение датащитов. Чтение их обязательно. Цель числовых значений в базе - сузить область выбора, тех компонентов, для которых потребуется прочитать датащиты перед принятием окончательного решения об использовании того или иного компонента в схеме.

Подписываюсь под каждым словом.

[Uladzimir 90]

Помните, что многие не имеют даже понятия о контроле версий и об SVN.

Глубоко копнули. Я думаю, что сюда смело можно отнести и Access :(

А что мешает выделить число в PDF и нажать Ctrl+C и Ctrl+V?

На данный момент я именно так и пользуюсь. Жаль не везде копировать дают. Либо закрыта, либо страница получена ксерокопированием

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

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

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

Пуст это выползает как подсказка при наведении курсора на параметр или еще как либо-- это второй вопрос.

То есть должно быть расширенное описание краткого названия параметра

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

С этим делом тут хорошо

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

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

Давайте устаканим. В этой ветке наиболее интересны все из перечисленных

[тау 31]

Простите, о каких полях вы говорите?

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

Кроме того , как токо делаете реплицированную базу, в ней автоматом заводится штук 15-16 "лишних " таблиц , которые скрыты , но место жрут.

Кроме того еще, как токо возник конфликт , в базе акцеса возникает дубль таблицы с конфликтом. Например была таблица "диоды" , возникнет таблица "Диоды_conflict" которая обязательно будет в списке как при выборе из библиотеки на схему , так и при просмотре dblib файла. Считаю это непреодолимым геморроем.

Репликацию фтопку :).

 

P.S. С SVN тоже оказывается не все гладко. Так как я описывал не работает - при каждой репликации в базу ACL.mdb вносятся изменения, а значит после сразу реплики ее необходимо снова заливать на SVN, даже если никаких изменений ползователь не вносил.

работа с базой черз SVN по моему глубокому убеждению - мазохизм.

[Krys 2]

Ну, причем же здесь частота изменений? Если ошибка будет исправлена только к следующему запуску, или вообще через десять лет, то разве от этого легче?

Кроме того, поверьте, на первом этапе наполнения базы конфликтов будет как раз очень много. Это по опыту.

Я только после этого сообщения понял, о каких конфликтах Вы говорите:

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

Давайте тогда конкретизируем терминологию. То, что Вы подразумеваете под конфликтами - это называется в русском языке (в обычном русском языке, без применения технической терминологии) "недостатки компонентов". Или "недоработки". Или даже "ошибки в компоненте". Но никак не "конфликты". Потому что конфликты - это чего-то с чем-то или кого-то с кем-то. При том непонятно кого и с кем.

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

Именно в таком контексте я написал:

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

 

Все согласны с такой терминологией?

 

[vitan 2]

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

Это, собственно, отдельная работа. Мне потребовалось недели три, чтобы систематизировать параметры для каждой группы компонентов. И то я вижу, что Вы уже предложили параметр Imax, которого у меня для конденсаторов нету. Это можно отдельно обсудить, думаю будет очень полезно.

 

То есть должно быть расширенное описание краткого названия параметра

Ну да, пока у меня просто текстовая строка с описанием. Потом усовершенствую.

 

Давайте устаканим. В этой ветке наиболее интересны все из перечисленных

Устаканим типы данных или наборы? Или и то и другое?

 

Репликацию фтопку :).

 

работа с базой черз SVN по моему глубокому убеждению - мазохизм.

В общем, да, как-то так... :)

 

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

Что Вы понимаете теперь уже под коллизией? :)

Если это проблема предоставления первоочередного права изменять данные, то Ваше понимание неправильное.

Если это проблема несовпадения данных внутри поля, то - правильное.

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

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

Поэтому термин "конфликт" не надо трогать. Путь будет стандартное понимание.

 

[тау 31]

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

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

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

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

[Uladzimir 90]

Кроме того еще, как токо возник конфликт , в базе акцеса возникает дубль таблицы с конфликтом. Например была таблица "диоды" , возникнет таблица "Диоды_conflict" которая обязательно будет в списке как при выборе из библиотеки на схему , так и при просмотре dblib файла. Считаю это непреодолимым геморроем.

Репликацию фтопку :) .

 

работа с базой черз SVN по моему глубокому убеждению - мазохизм.

Конфликт подтверждаю. Было тоже такое

[vitan 2]

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

Да. И тут возникает вопрос из серии "а судьи кто?". Кто будет синхронизировать все это? Некий сисадмин-супервизор-библиотекарь, учитывающий интересы всех мелких пользователей, и не дающий им подраться? Уверен, это тупик.

Гораздо лучше, имхо, система с рейтингами, общим доступом и механизмами workflow для организации _коллективных_ проверок.

Но, возможно, и это не предел, просто я лично предложить что-то лучшее пока не могу.

[Uladzimir 90]

Это, собственно, отдельная работа. Это можно отдельно обсудить, думаю будет очень полезно.

 

Ну да, пока у меня просто текстовая строка с описанием. Потом усовершенствую.

 

Устаканим типы данных или наборы? Или и то и другое?

Да. отдельная. И я не думал ее затевать, создавая эту ветку.

Но раз ввязываемся, ну что ж давайте

Строки с описанием достаточно. Главное чтоб она мозолила глаза и была динамической при смене типа компонента

Ну нужно и то и другое. Так как они связаны.

Определяем конкретный тип и к нему предлагаем наборы.

И первое и второе расширяется по мере создания новых типов или внесения "забытых" данных

[vitan 2]

Да. отдельная. И я не думал ее затевать, создавая эту ветку.

Но раз ввязываемся, ну что ж давайте

Есть предложение начать это дело в форуме по библиотекам для привлечения большего количества народу, не только альтиумовцев.

И обсуждать отдельно:

- вообще сами библиотеки компонентов (какие именно нужны, деление, иерархию);

- параметры компонентов, необходимые для каждой библиотеки;

- типы данных;

- группировку параметров в наборы.

Больше толку будет имхо.

[jkrieger 0]

Есть предложение начать это дело в форуме по библиотекам для привлечения большего количества народу, не только альтиумовцев.

И обсуждать отдельно:

- вообще сами библиотеки компонентов (какие именно нужны, деление, иерархию);

- параметры компонентов, необходимые для каждой библиотеки;

- типы данных;

- группировку параметров в наборы.

Больше толку будет имхо.

Поддерживаю.

 

 

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

Кроме того , как токо делаете реплицированную базу, в ней автоматом заводится штук 15-16 "лишних " таблиц , которые скрыты , но место жрут.

Кроме того еще, как токо возник конфликт , в базе акцеса возникает дубль таблицы с конфликтом. Например была таблица "диоды" , возникнет таблица "Диоды_conflict" которая обязательно будет в списке как при выборе из библиотеки на схему , так и при просмотре dblib файла. Считаю это непреодолимым геморроем.

Репликацию фтопку :).

 

работа с базой черз SVN по моему глубокому убеждению - мазохизм.

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

 

По поводу "жрут место".... Вам жалко? По-моему сейчас не то время, когда ценится место на винте.

 

БД через SVN - мазохизм =) Но другого я пока реализовать не могу.

 

 

 

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

 

[тау 31]

По поводу "жрут место".... Вам жалко? По-моему сейчас не то время, когда ценится место на винте.

еще они будут жрать трафик (время на скачку) . Пухнет реплика раза в два. База от нескольких пользователей будет на много мегабайтов. Интернет не у всех безлимитный и быстрый.

 

[vitan 2]

БД через SVN - мазохизм =) Но другого я пока реализовать не могу.

Поймите, если Вы - мазохист, то это не значит, что таковыми должны становиться окружающие. :) Это Вы должны-таки измениться. :)

 

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

Это прекрасное и чистое как горный родник желание! Даже странно, как оно родилось в такой мазохистской голове... :)

Ладно, Вам же описали все минусы, связанные с этим. Вы считаете, не достаточно? Вы сможете их устранить, оставив репликацию, как основной механизм? Тогда - пожалуйста! Если нет, то, думаю, пользователей будет не много...

[jkrieger 0]

Поймите, если Вы - мазохист, то это не значит, что таковыми должны становиться окружающие. :) Это Вы должны-таки измениться. :)

 

 

Это прекрасное и чистое как горный родник желание! Даже странно, как оно родилось в такой мазохистской голове... :)

Ладно, Вам же описали все минусы, связанные с этим. Вы считаете, не достаточно? Вы сможете их устранить, оставив репликацию, как основной механизм? Тогда - пожалуйста! Если нет, то, думаю, пользователей будет не много...

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

 

еще они будут жрать трафик (время на скачку) . Пухнет реплика раза в два. База от нескольких пользователей будет на много мегабайтов. Интернет не у всех безлимитный и быстрый.

Кстати вот тут меня спасает мазохизм =) Через SVN вы не будете качать весь файл. Только изменения.