[Uladzimir 72]

Про небольшое число пользователей.

Я все хочу довести мысль, что база нужна не только рисовальщикам схем. Вы правильно говорите, что кто хочет, тот и заполняет. Только это входит в противоречие с понятием целостности данных. Надо объяснять, зачем она нужна? Все связанные поля при добавлении новой записи в БД должны быть заполнены. Можно принять, что по-умолчанию программа-клиент будет писать туда что-то типа N/A, но тогда кому такая база нужна? Проще говоря, это называется халявой.

Правильно. не только. Я склад не могу заставить. А надо

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

Кому надо, то берет с линком, кому нет- не берет.

Если в базе нет линка-- нет этой информации. Кто-то допишет.сам если потребуется. И по доброте душевной выложит.

Специально все это собирать и писать-- библиотекарь костьми ляжет.

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

Про линки. Я уже говорил, что, к примеру, ROHS должен быть не строкой, а линком,

Вот. с линком пришли к единому мнению. Все это к технологу

 

Неверно. Разработчик...

Ладно. кусаю ногти. Имел ввиду схемотехника. Разработчик-- это бог :)

если тополог выбирает неправильный текстолит,

Ну текстолит это материал, и в базу не попадет.

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

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

Гм. Надо смотреть тогда глубже.

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

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

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

Если снят с производства -- не чего его в базу заносить. А если уж там есть-- помечать или удалять сразу.

 

 

 

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

 

Запросы можно будет делать свои в базе-реплике. Так как запросы и формы не реплицируются, то каждый сможет нагородить в базе-реплике что угодно. Реплицироваться будут только нужные таблицы с компонентами. Так что свобода самовыражения останентся =)

 

Пока привожу шаблон базы как я ее вижу. Это только заготовочка. В каждой таблице только обязательные поля. Еще будут поля параметров для каждой таблицы. Но то потом и неизвестно востребовано ли оно будет.

Какие таблицы (категории компонентов) и поля следует добавить/удалить?

 

UPD: я не создавал таблиц для п.п.18 - 24. И слабо представляю какими они должны быть

acl.zip

 

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

Ключевые поля класс работают, это радует.

Вот моя старая база. посмотрите. Там форма совмещенная с таблицей.

Может навеет на что

[vitan 2]

Правильно. не только. Я склад не могу заставить. А надо

Не надо. Они сами должны к этому прийти. А Вы покажете пример. Иначе ничего не выйдет.

 

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

Вы думаете, завод Вам обеспечит сладкую жизнь? Вы пробовали заказать расчет импедансов, скажем, в Резоните?

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

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

 

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

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

К общей базе надо стремиться, не пытаться сделать сразу, а именно стремиться.

 

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

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

 

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

Ого! А что ж Вы тогда ее затеяли? Вы действительно будете каждый раз изучать PDF на резистор, когда Вам нужно будет поставить новый номинал? Или Выберете из базы, не задумываясь, и зная, что там все уже проверено?

 

Если снят с производства -- не чего его в базу заносить. А если уж там есть-- помечать или удалять сразу.

Ну-ну. А с заделом, к примеру, что делать?

 

Вот моя старая база. посмотрите. Там форма совмещенная с таблицей.

Может навеет на что

А где?

[jkrieger 0]

Версия для Access 2000

 

UPD: По поводу форм. Если честно, у меня не получилось нормально сделать форму.

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

[Uladzimir 72]

Вы пробовали заказать расчет импедансов, скажем, в Резоните?

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

А я должен учесть требования завода

А еще, компоненты ROHS нельзя применять

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

К общей базе надо стремиться, не пытаться сделать сразу, а именно стремиться.

Золотые слова. Лучшее враг хорошего.

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

По мере наполнения и совершенствования базы-- все будет.

Пока ничего нет, и если заказывать в базу опись подштаников-- то ничего и не будет. Только говорильня

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

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

А где?

Забыл. :(

Вечером

 

UPD: По поводу форм. Если честно, у меня не получилось нормально сделать форму.

 

Это легко. Зато удобно

Вечером выложу базу, там есть такая форма

[vitan 2]

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

Итак, Вы согласны с концепцией одного справочника на все типы компонентов?

Обсудим другие необходимые справочники?

 

Забыл. :(

Вечером

Если можно, в старом аксессе.

[Uladzimir 72]

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

Итак, Вы согласны с концепцией одного справочника на все типы компонентов?

Обсудим другие необходимые справочники?

 

 

Если можно, в старом аксессе.

Я нет. Не мне ее создавать. Мне своих хватает

Вот отпугнуть юзеров--- Это 100% , А база задумывается для них, или для совместного пользования

Чтоб узнать путь правильный, или нет, по нем надо хотя бы идти, а не разговаривать как идти.

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

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

На счет других справочников. Что мы еще забыли-- Карты настройки?

[vitan 2]

Чтоб узнать путь правильный, или нет, по нем надо хотя бы идти

Что-то я Вас перестаю понимать. Я ходил и пытаюсь Вам сказать, куда ходить не надо.

а не разговаривать как идти.

Так закройте топик! Действительно, чего зря болтать, дело надо делать! :)

 

Справочник всегда один.

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

Посему два вопроса.

1. Вы согласны с таким способом хранения информации, или предпочитаете иметь разные таблицы для резисторов, конденсаторов и т.п.?

2. Если согласны, то готовы ли Вы обсудить, какие другие объекты, кроме компонентов, должны быть в базе, т.е. какие еще нужны справочники?

[Uladzimir 72]

Что-то я Вас перестаю понимать. Я ходил и пытаюсь Вам сказать, куда ходить не надо.

Нет. пока я вижу, что вы пишете куда надо идти. А это не одно и тоже

Так закройте топик!

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

Шла речь как лучше, проще и удобней их строить

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

Я не только предложил, но и привел их список.

Мы обсудили отдельные поля, однако в процессе обсуждения

В основном это касалось Rosh.

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

В целом как и цвет клеммника, который тоже важен!!! И таких параметров можно найти тысячу и еще один.

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

Вы же стоите но позиции-- каждому свойству- свой параметр, или я не правильно понял?

Если это концепция-- я не согласен, и готов дискутировать

1. Вы согласны с таким способом хранения информации, или предпочитаете иметь разные таблицы для резисторов, конденсаторов и т.п.?

Не внимательно читали. Я уже писал выше. Можно и так итак.

Либо Общую получать запросами, либо частные формировать запросами.

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

2. Если согласны, то готовы ли Вы обсудить, какие другие объекты, кроме компонентов, должны быть в базе, т.е. какие еще нужны справочники?

На данном этапе - никакие. Так как базы вообще ни, нет даже полей для ввода параметров

 

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

Но на этом этапе нет.

 

Еще раз повторю.

Я давно работаю с базой и меня оно более менее устраивает

Здесь речь пошла у совместной базе и выработке ее структуры.

Давайте начнем со скелета, и хотя бы увидим там те параметры, о которых спора нет

[vitan 2]

Нет. пока я вижу, что вы пишете куда надо идти. А это не одно и тоже

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

 

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

В целом как и цвет клеммника, который тоже важен!!! И таких параметров можно найти тысячу и еще один.

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

Вы же стоите но позиции-- каждому свойству- свой параметр, или я не правильно понял?

Если это концепция-- я не согласен, и готов дискутировать

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

Очевидно, в базе должна содержаться некая информация, доступная без "дешифрации". И о необходимости этой информации, мы, собственно, и разговариваем. Так вот, чертов ROHS я лично считаю необходимым по причинам, изложенным выше.

 

Не внимательно читали. Я уже писал выше. Можно и так итак.

Либо Общую получать запросами, либо частные формировать запросами.

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

Господи, да читал я! Вы свое мнение можете выразить, наконец, а не перечислять возможные варианты? Я считаю, что это очень принципиально, почему уже тоже написал.

 

На данном этапе - никакие. Так как базы вообще ни, нет даже полей для ввода параметров

А чем этот этап такой особенный? Ну и что, что ее нет живьем. Я уже говорил, что думаю, она, даже не появится. Но это же не повод останавливаться. Вдруг кто-нибудь из нас решит выложить свою базу для общего пользования. Да и просто усовершенствовать никогда не помешает. Так вот, помимо компонентов предлагаю-таки начать со справочника УГО, как наиболее близкого нам, рисовальщикам.

Нет возражений, что УГО надо группировать по библиотекам?

 

Я давно работаю с базой и меня оно более менее устраивает

Здесь речь пошла у совместной базе и выработке ее структуры.

Давайте начнем со скелета, и хотя бы увидим там те параметры, о которых спора нет

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

[Uladzimir 72]

Зачем столбцы с футпринтом?

Это не то, что написано в PDF, а то как имя реального Footprint, который автоматически подключается при передачи изменений из схемы в PCB

Вдруг кто-нибудь из нас решит выложить свою базу для общего пользования.

Ну так давайте. Насколько я понял у Вас тоже есть?

УГО надо группировать по библиотекам

Вот тут я категорически против.

Хотя раньше был на этой позиции

[vitan 2]

Это не то, что написано в PDF, а то как имя реального Footprint, который автоматически подключается при передачи изменений из схемы в PCB

Правильно. Очевидно, в PDF и в базе будут разные обозначения футпринтов. Поэтому это поле нужно, т.к. его "дешифрировать" из PDF не получится. Та же ситуация и другими полями, в т.ч. пресловутым ROHS.

 

Ну так давайте. Насколько я понял у Вас тоже есть?

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

 

Вот тут я категорически против.

Хотя раньше был на этой позиции

И? Сначала уж скажите почему, а то я все вещаю, а меня начинают упрекать, что я, мол, начинаю всех жизни учить... :)

[Uladzimir 72]

Очевидно, в PDF и в базе будут разные обозначения футпринтов.

Естественно. В PDF указан тип корпуса, а не Footprint

Последний учитывает и способ монтажа.

Это разные вещи в принципе.

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

Правильно вы заметили, что та же ситуация что и "в т.ч. пресловутым ROHS."

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

Замечу. Я ведь не настаиваю на параметре "тип корпуса".

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

Вы же знаете, что в разных стандартах один и тот же корпус имеет разное обозначение?

сть-то есть, но вот дать пока не получится. Ибо все сделано не в аксессе

Это не важно. Достаточно скреен название столбцов, строк., таблиц...

И? Сначала уж скажите почему, а то я все вещаю, а меня начинают упрекать, что я, мол, начинаю всех жизни учить... smile.gif

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

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

Кто пользуется знает как....

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

2. Если она изменилась-- неизвестно какие компоненты подверглись изменению

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

4...

[jkrieger 0]

1. Вы согласны с таким способом хранения информации, или предпочитаете иметь разные таблицы для резисторов, конденсаторов и т.п.?

2. Если согласны, то готовы ли Вы обсудить, какие другие объекты, кроме компонентов, должны быть в базе, т.е. какие еще нужны справочники?

1. С одним справочник на все компоненты не согласен. Мне кажется будет лучше разделить их на каттегории - транзисторы, резисторы, микросхемы, выключатели и т.п. Зачем? В каждой таблице кроме основных полей будут поля, относящиеся к конкретной категории, например, тип транзистора (NPN, PNP, MOSFET-N....). Это пригодится для сортировки и группировки компонентов уже в Альтиуме. Конечно не все параметры будут записываться, а какие-то самые важные.

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

 

Теперь вопрос знатокам Access. Можно ли связать две таблицы в разных файлах по двум ключевым полям? А в одном файле?

 

[Uladzimir 72]

В разных файлах не знаю, в одном просто

в меню Pabota c бфзами данных/ схема данных.

Там понятно

[тау 31]

Можно ли связать две таблицы в разных файлах по двум ключевым полям? А в одном файле?

я не знаток , но попробую ответить.

на главном окне базы в Access по контекстному меню щелкаете "связь с таблицами" . Предложит выбрать другую mdb базу и таблицы из неё по вашему выбору.

Выбрали - эти таблицы теперь появились в исходной базе (выделяются стрелочками слева от значков обычных таблиц)

 

Вот теперь между всеми таблицами , имеющимися и связанными ( по ссылкам ) можете проводить связи в "схеме данных"

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

 

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

Запросам в этом случае пофиг - есть связь или нет . По барабану то-есть.