[vitan 2]

Есть ли возможность как то в самой базе определить какой пин уго соответствует паду корпуса?

Я не парился и создал кучу УГО. :)

[Krys 2]

Теперь про группировку. Разве не нормально группировать, скажем, УГО резисторов в отдельную группу, УГО конденсаторов - в отдельную, и т.д.?

Напомню, речь об этом сообщении (#187): http://electronix.ru/forum/index.php?s=&am...st&p=823647

И в нём говорится не о вообще нецелесообразности группировки файлов с УГО по папочкам или группировки компонентов по их функции. Говорится о нецелесообразности одному компоненту давать несколько ссылок на несколько УГО. Т.е. каждому компоненту сопоставлен только одно УГО. Точнее один файл *.schlib (если говорить конкретно об АД), если в каждом файле лежит по одному УГО. Либо один элемент (ячейка, строка таблицы SCH Library Panel) такого файла, если в каждом файле по нескольку УГО для разных компонентов.

Как говорилось выше, одного УГО на один компонент достаточно по причине того, что (по крайней мере в АД) один УГО может содержать разные представления (альтернативные виды). А каждый вид может содержать составляющие (Part). Если в других САПР не поддерживается несколько альтернативных видов на один УГО, тогда, действительно, необходимо в нашу базу (или систему, я так и не понял отличие базы от системы, прошу конкретизировать эти понятия в том вордовском документе с определениями) заложить несколько полей для альтернативных УГО. Прошу знающих другие САПР уточнить этот вопрос. Мы же стремимся, чтобы наша система (или база) годилась для любой САПР?...

 

[jkrieger 0]

САПР может подключиться и к локальной БД (слепка БД из инета) И к БД из интернета.

Этому никто не мешает и пользователь сам может определить с какой ему работать . Это на любителя и требование к общей БД не ограничивает

Мне кажется ограничивает. Если подключаться сразу к Общей БД прямо из САПР, то как вы собираетесь отслеживать новые компоненты? Допустим их кто-то добавил, модератор проверил и отметил, что проверено. Но разве вы сами не захотите проверить его лично? А в этом случае вы даже не узнаете что он добавился. Он просто тихонько появится в списке доступных компонентов.

 

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

 

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

Не соглашусь. Клиент тоже не знает что ему делать с данными, пока не поймем это мы. В моем понимании задача клиента отправлять запросы SQL через HTTP и принимать данные. И всего-то. Вы же не будете получать все данные и анализировать какие-то условия программно (то есть на языке программирования). Это удобнее сделать на языке SQL, составив правильный запрос.

 

Поэтому если будет доступ к локальной и глобальной базе из одной СУБД (для MySQL из его клиента, я ж так понимаю это чать СУБД?), то можно будет выполнять запросы прямо в ней.

Постараюсь отобразить это так:

|MS Access| - Рабочая база
|         | - MyODBC ------- Общая БД

Тут Рабочая и Общая БД в Аццесе будут видны как обычные две таблицы. И я могу строить запросы прямо в СУБД (Access).

 

Остается вопрос: кто в описанной модели с аксессом будет выполнять добавление и изменение компонентов в основной БД? Тот же клиент?

Думаю проще будет это делать через web-формы на сервере, где хранится база. Хотя как лучше и удобнее надо подумать.

[Uladzimir 93]

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

Здесь тоже один файл - одно УГО. и я за это выступаю.

Из нескольких УГО можно сочинять сложные УГО.

Здесь это не так. так нельзя. Те части, из которых состоит сложное УГО, называется PART, и последние не имеют самостоятельного хождения.

Не знаю ментора. Но и там думаю в этом вопросе должны быть сложности. Или гдето еще нужно хранить присвоение номерa PIn. Иначе при построении сложного УГО неизбежны конфликты

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

Ну насчет сапро независимости-- все просто. Все равно УГО от ментора не подойдет алтиуму и на оборот.

Просто нужно знать, что для алтиума ссылка на УГО всегда одна, и там находится все.

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

Выбор текущего САПР должен быть заложен в настройках.

Нет возражений?

Перефразирую.

Таким образом, в БД (ДЛЯ ALTIUM)должны быть перечислены все (Для ALTIUM ОДИН) УГО компонента. УГО будет взят из библиотеки УГО, на которую указана ссылка в базе для конкретного компонента (точнее, за библиотекой компонентов).

А вот ссылки на сами файлы с УГО должны формироваться по правилам, которые зависят от конкретного САПР. Например, для альтиума, в БД должна содержать ссылку на ОДИН УГО компонента, который содержит все виды альтернативных изображений и ВСЕ PART (составные части УГО).

Для другого САПР будет сформирована другая строка, в моем случае это будет просто перечисление через запятую.

Для другого САПР по запросу , ориентированном на конкретный САПР, будет формирована другая строка, в моем случае это будет просто перечисление через запятую.

 

Напомню,

Вот тут более удачно приведено особенность алтиума

[vitan 2]

Напомню, речь об этом сообщении (#187)

...

Вы, видимо, не успели прочитать это...

 

Мне кажется ограничивает. Если подключаться сразу к Общей БД прямо из САПР, то как вы собираетесь отслеживать новые компоненты? Допустим их кто-то добавил, модератор проверил и отметил, что проверено. Но разве вы сами не захотите проверить его лично? А в этом случае вы даже не узнаете что он добавился. Он просто тихонько появится в списке доступных компонентов.

А что мешает сделать оповещения, например, по e-mail? Опять же, рейтинг... Наконец, поле NEW, сбрасывающееся по тайм-ауту через неделю...

Было бы желание...

 

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

Видеть изменения - действительно очень важно. Только я считаю, что это надо делать не локальными базами, а хранить в общей БД историю изменений компонента и выводить ее при необходимости в клиенте. У меня так и сделано.

 

Не соглашусь. Клиент тоже не знает что ему делать с данными, пока не поймем это мы. В моем понимании задача клиента отправлять запросы SQL через HTTP и принимать данные. И всего-то. Вы же не будете получать все данные и анализировать какие-то условия программно (то есть на языке программирования). Это удобнее сделать на языке SQL, составив правильный запрос.

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

В аксессе с этим есть определенные проблемы (да и не только с этим), но мое мнение про него Вы уже знаете.

[Uladzimir 93]

Мне кажется ограничивает. Если подключаться сразу к Общей БД прямо из САПР, то как вы собираетесь отслеживать новые компоненты? Допустим их кто-то добавил, модератор проверил и отметил, что проверено. Но разве вы сами не захотите проверить его лично? А в этом случае вы даже не узнаете что он добавился. Он просто тихонько появится в списке доступных компонентов.

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

И он сам на это решился.

Тут контроль только один-- можно смотреть дату модификации

Не соглашусь. Клиент тоже не знает что ему делать с данными, пока не поймем это мы.

Соглашаюсь. типовые запросы должны быть предоставлены.

А опытные пользователи уже потом и сами могут их написать. Но заготовки запросов быть обязаны.

Первый зашедший должен работать сразу-- а не разбираться в структуре базы

[vitan 2]

Просто нужно знать, что для алтиума ссылка на УГО всегда одна, и там находится все.

 

Перефразирую.

Таким образом, в БД (ДЛЯ ALTIUM)должны быть перечислены все (Для ALTIUM ОДИН) УГО компонента. УГО будет взят из библиотеки УГО, на которую указана ссылка в базе для конкретного компонента (точнее, за библиотекой компонентов).

А вот ссылки на сами файлы с УГО должны формироваться по правилам, которые зависят от конкретного САПР. Например, для альтиума, в БД должна содержать ссылку на ОДИН УГО компонента, который содержит все виды альтернативных изображений и ВСЕ PART (составные части УГО).

 

Для другого САПР по запросу , ориентированном на конкретный САПР, будет формирована другая строка, в моем случае это будет просто перечисление через запятую.

Опять консенсус. :)

[Uladzimir 93]

А что мешает сделать оповещения, например, по e-mail?

Отвратительно. Это хуже чем спам. все отключат это

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

В аксессе с этим есть определенные проблемы (да и не только с этим), но мое мнение про него Вы уже знаете.

Поймите схемотехник не программист. Ему это не надо.

Заготовка типового запроса ОБЯЗАТЕЛЬНА.

А опытные и знающие программный аспект базы-- все равно под себя напишут. Но таких хорошо если процент от общего числа будет

[vitan 2]

Первый зашедший должен работать сразу-- а не разбираться в структуре базы

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

В курсе, что делает запрос, например, DROP TABLE Components; :)

[Uladzimir 93]

Опять консенсус. :)

Ну да. Сначала нужно копья обломать,

А потом убедится что все говорили об одном и том же, только разными словами :)

 

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

В курсе, что делает запрос, например, DROP TABLE Components; :)

 

Понятия не имею. Но я хотел бы иметь

Export for Altium :)

[vitan 2]

Поймите схемотехник не программист. Ему это не надо.

Начинаем опять ходить по кругу? У Вас опять нет времени и возможностей?

 

Заготовка типового запроса ОБЯЗАТЕЛЬНА.

А опытные и знающие программный аспект базы-- все равно под себя напишут. Но таких хорошо если процент от общего числа будет

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

[тау 31]

Не соглашусь. Клиент тоже не знает что ему делать с данными, пока не поймем это мы. В моем понимании задача клиента отправлять запросы SQL через HTTP и принимать данные. И всего-то. Вы же не будете получать все данные и анализировать какие-то условия программно (то есть на языке программирования). Это удобнее сделать на языке SQL, составив правильный запрос.

Соглашайтесь пока непоздно, Vitan правильно сказал насчет СУБД. Клиент не только запросы посылает, а еще и данными манипулирует так, как заказано было программисту при написании клиента, и все ведь для удобства конечного (оконченного :) ) юзера.

 

Соглашаюсь. типовые запросы должны быть предоставлены.

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

[vitan 2]

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

:) А Вы не пробовали динамически генерить таблицы? Мы вот вынуждены так поступать из-за особенностей одной проги...

[Uladzimir 93]

Начинаем опять ходить по кругу? У Вас опять нет времени и возможностей?

 

 

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

Нет желания становится программистам.

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

И сделать это я должен просто интуитивно, без чтения книг по CИ++, джаве али еще чему либо.

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

[тау 31]

:) А Вы не пробовали динамически генерить таблицы? Мы вот вынуждены так поступать из-за особенностей одной проги...

все время "точить " базу - некошерно !

сетка грузится.

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