[vitan 2]

Вот давайте эти пару десятков параметров в начале и определим.

Из общих -- только рассеиваемая мощность на все виды компонентов распространяется., да и то не на все.

Не на все. На все - у меня из тех, что нужны - только рабочая температура (мин. и макс.) и еще конструктора попросили температуру хранения (тоже две штуки).

 

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

Конечно! Я уже давно говорю.

 

Картинка хорошо. Но хотелось бы пройти именно подключение через ODBC драйвер.

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

А в чем интерес-то? Ну, увидите циферки, ну и что? Они как везде одинаковые...

Или есть сомнения, что вообще можно работать через ODBC?

По-моему Вы выше писали, что альтиум может работать через HTTP. Тогда вообще можно не стремиться к ODBC, а использовать коннект к БД через цепочку (альтиум)-(HTTP)-(ODBC\JDBC\что-то еще)-(БД).

 

Кстати при связи с Access базой, в нее можно вносить изменения или новые записи прямо из Altium.

Вон оно как! Так и клиент тогда не нужен! Клиентом тогда является сам альтиум.

[Uladzimir 96]

Вон оно как! Так и клиент тогда не нужен! Клиентом тогда является сам альтиум.

Гм. вы меня радуете.

Что ж, будет дырка свободная -- попробую.

К хорошему нужно стремиться.

[vitan 2]

Вот, для иллюстрации того, что говорил выше. Схема нашей БД на двух листах формата А0. :)

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

Diagram_0.rar

[Uladzimir 96]

Ну вот наконец предмет для обсуждения.

При первой оказии добавлю комментарий

[Krys 2]

Поиск все равно идет по тексту. В принципе достаточно.

хотя конечно да. Но пока и самого инструмента нет для параметрического доступа. Только закладывать или не закладывать.

Конечно закладывать. Поиск по тексту - это несерьёзно. Потому что кто-то обязательно напишет не Um = 15 V, а Vм = 15 В. А проверяющие не увидят или лень будет дрючить автора и править самому.

 

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

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

 

Вот, для иллюстрации того, что говорил выше. Схема нашей БД на двух листах формата А0. :)

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

Обалдеть! Вот бы у нас на предприятии такую внедрить...

- Нет, сынок, это фантастика... :))

 

[vitan 2]

Конечно закладывать. Поиск по тексту - это несерьёзно. Потому что кто-то обязательно напишет не Um = 15 V, а Vм = 15 В. А проверяющие не увидят или лень будет дрючить автора и править самому.

+1. Числа надо хранить в полях с числовым типом данных, строки - в полях со строковыми и т.п.

Это предлагаю не обсуждать.

 

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

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

 

- Нет, сынок, это фантастика... :))

Это реальность. Это (и многое другое) у нас создают 2 (два) человека, причем лично я ничего не пишу, а только ставлю задачи. :) А тот, кто пишет, умудряется параллельно паять микросхемы. При этом юзается это тоже двумя схемотехниками, один из которых - я же. Раньше, правда, до 6 человек доходило... Вот такие причуды капитализма...

Но эффект налицо. Поверьте, за это стоит браться. Глаза боятся, а руки делают.

[Uladzimir 96]

+1. Числа надо хранить в полях с числовым типом данных, строки - в полях со строковыми и т.п.

Это предлагаю не обсуждать.

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

Насчет чисел не знаю не смотрел.

Но с предлагаемым типом абсолютно согласен.

Минусы - большое количество библиотек

Не соглашусь. Это плюс. Лучше много маленьких чем несколько больших. Устойчивость к падению лучше

нужны правила именования

Нужны, я постоянно об этом твержу.

Вообще любой вопрос должен начинаться с главы "термины и определения". Это еще до правил нужно.

[vitan 2]

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

Насчет чисел не знаю не смотрел.

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

У меня все единицы измерения в системе СИ, поэтому 1 мкФ хранится как 0,000001 Ф. При просмотре базы клиент (схемотехнический редактор) сам преобразует это число в 1 мкФ (точнее, в 1uF), подставляя приставку "u", которая ему задана в списке разрешенных приставок. Когда юзер ставит кондюк на схему, у него появляется свойство VALUE с _текстовым_ значением 1uF. Это так работает ментор, там все свойства текстовые.

Так вот, если в БД будут не числовые поля, то, возможно, такая расстановка приставок может не заработать.

 

Не соглашусь. Это плюс. Лучше много маленьких чем несколько больших. Устойчивость к падению лучше

Ну да, это минус только на первое время. А так - одни плюсы. :)

[Uladzimir 96]

При просмотре базы клиент (схемотехнический редактор) сам преобразует это число в 1 мкФ (точнее, в 1uF), подставляя приставку "u", которая ему задана в списке разрешенных приставок. Когда юзер ставит кондюк на схему, у него появляется свойство VALUE с _текстовым_ значением 1uF. Это так работает ментор, там все свойства текстовые.

Это означает, что нужно писать скрипт в схемотехническом редакторе. Это есть недостаток. Так как некоторые редакторы (не алтиум) могут этого и не позволять.

Возможно это следует сделать в самой базе дублирующим параметром уже в текстовом виде?

[vitan 2]

Возможно это следует сделать в самой базе дублирующим параметром уже в текстовом виде?

Думаю, что не надо, потому что альтиум наверняка это тоже умеет. По крайней мере два его конкурента умеют.

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

Но, еще раз: думаю, что все должно работать и в альтиуме. Просто проверьте.

[Uladzimir 96]

В алтиуме работает.

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

Поэтому механизм должен быть. А пользоваться или нет-- это дело уже клиента.

Для клиента нужно предоставить все удобства.

 

Пусть меня поправят, уточнят, напишут лучше.

Вот начал.

Что получилось за 10 минут.

 

Термины и определения

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

Примеры разновидностей компонентов.

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

Посадочное место -- графическое изображение компонента для редактора PCB. Footprint может иметь одно или несколько альтернативных изображений. . УГО могут иметь параметры.

Модель – графические или текстовые данные компонента для симуляции, построения 3-мерных моделей и иных целей.

Компонент –набор параметров, ссылок на иные компоненты, объединяющих информацию об изделии в единое целое.

Простая Библиотека. Файл или директория файлов, в которых хранится данные компонентов одного типа

Смешанная библиотека. Файл или директория файлов, которых хранится данные компонентов

Хранилище – Указание мест, где находятся библиотеки

 

[Krys 2]

1. Компонент библиотеки— графическая, текстовая и иная информация, имеющая законченный вид и имеющая собственное имя внутри библиотеки.

Примеры разновидностей компонентов.

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

1.2.Посадочное место -- графическое изображение компонента для редактора PCB. Footprint может иметь одно или несколько альтернативных изображений. . УГО могут иметь параметры.

1.3.Модель – графические или текстовые данные компонента для симуляции, построения 3-мерных моделей и иных целей.

2. Компонент –набор параметров, ссылок на иные компоненты, объединяющих информацию об изделии в единое целое.

3. Простая Библиотека. Файл или директория файлов, в которых хранится данные компонентов одного типа

4. Смешанная библиотека. Файл или директория файлов, которых хранится данные компонентов

5. Хранилище – Указание мест, где находятся библиотеки

Мои коррективы:

1.2. упоминается термин Footprint без его предварительного определения. Упоминается УГО.

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

2. Не совсем понял, зачем в компоненте "ссылки на иные компоненты". Может, лучше упомянуть "ссылки на модели и УГО"? Можно ещё прибавить "ссылки на документацию, поставщиков" и т.п.

4. Чтобы п. 4 отличался от п. 3 предлагаю конкретизировать: "данные компонентов разного типа" (плюс ошибка: хранЯтся). А чтобы было понятно, что значит одного типа и разного типа, нужно дать определение "тип компонента". И ещё вопрос по п. 3 и 4: а библиотекой нельзя назвать файл или директорию файлов, где хранятся не данные компонентов, а данные моделей или УГО? Т.е. не компонентов в целом, а их составляющих.

5. Хранилище - это чисто из русского языка - само место, а не указание мест. А указание мест наверное лучше назвать "путь хранения"

Ну это так... пока просто пожелания...

А ещё предлагаю термины разместить в иерархическом порядке. Примерно так:

1. База. Составляющие:

1.1 библиотека. Составляющие:

1.1.1. Компонент. Составляющие:

1.1.1.1. УГО

1.1.1.2. Модель. Разновидности:

1.1.1.2.1. посадочное место

1.1.1.2.2. симуляционная модель

1.1.1.3. Параметры

Ну и т.д.

[Uladzimir 96]

Вот. начало второй редакции. Просьба там и делать пометки

[тау 31]

Конечно закладывать. Поиск по тексту - это несерьёзно. Потому что кто-то обязательно напишет не Um = 15 V, а Vм = 15 В. А проверяющие не увидят или лень будет дрючить автора и править самому.

я поиском не пользуюсь, достаточно классифицированных таблиц, содержимое которых не так уж и велико ( в любой конторе оно ограничено - это оздоровляет процесс логистики. Моё имхо в том что выбирать из базы компонент параметрическим поиском - это попытка отупеть за счет функционала базы. Параметрический поиск нужен несомненно при поиске компонента из очень больших баз, например посмотрите как сделан парам поиск в терраэлектронике. Нужно для этого наворачивать функционал КЛИЕНТА. Альтиум сам такого не может. Получается что в клиенте надо провести поиск , запомнить этот элемент где он и как назвается, потом в альтиуме его найти и плюхнуть на схему. Это неудобно несколько. Кроме того поиск ограничен только тем что занесено в базу , а это всегда ограниченный перечень который никогда не догонит перечень на сайтах производителей. На попытку "Догнать и перегнать" будет затрачено очень много коллективных усилий, а пока не хватает сил найти писателя клиента. Поэтому , раз база обсуждается применительно к работе только Альтиума, надо сделать максимально удобной работе именно в альтиуме, с учетом его ограниченных возможностей. Многие пользователи не будут пользоваться клиентом (лень, некогда), но скажут спасибо тем кто наполняет эту общественную базу.

 

Обалдеть! Вот бы у нас на предприятии такую внедрить...

- Нет, сынок, это фантастика... :))

У нас в конторе структура сложнее на порядок. Еще есть функционал и таблицы по складу (можно заказать комплектование заявки смотреть когда там уже идти на склад получать, зарезервироать компоненты), закупкам (процесс закупки заказанных компонентов отслеживается) , по рабочим спецификациям и учтенной КД, все в единой базе. Подсчет стоимости комплектации сборок и изделий. Это не "фантастика", и здорово облегчает процесс работы в целом.

 

 

[Uladzimir 96]

Вот. начало второй редакции. Просьба там и делать пометки

Обновил.

Terms_and_definitions._Database.zip