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

Когда голосовал, дрогнула рука. На второй вопрос пимпочка не выбралась (тыкал в SQL Server).
Можно это как-то поправить?

Добавьте, пожалуйста, в "Как у Вас организована база данных комопнентов DxDataBook (под управлением СУБД)" еще и CSV (текстовый файл).

Вы уже проголосовали, да? Тогда, наверно, уже поздно.
Этот вид организации мне очень интересен, т.к. он позволяет более быстро делать библиотеки для разных САПР, а не только для DxD. Скажите, а как Вы наполняете эти файлы и как следите за их содержимым? У Вас совсем нет БД или Вы все-таки экспортируете из нее в текстовые файлы?

Вот краткое описание моей DxDatabook.
Все это происходит под Windows.

Я исплользую Text ODBC driver чтобы обращаться в файлу CSV как к базе данных. Для редактирования CSV файла использую LibreOffice Calc.

Т.е. например есть каталог C:\project\expedition\dxdb в котором лежат файлы (см аттач):
dxdb.csv - БД
schema.ini - файл настройки таблиц БД для Text ODBC driver
dxdb.dbc - файл настройки DxDatabook

Ссылки по теме Text ODBC driver:

http://msdn.microsoft.com/en-us/library/wi...v=vs.85%29.aspx
http://msdn.microsoft.com/en-us/library/ms709353.aspx
http://www.expresscomputeronline.com/20031...chspace01.shtml
http://stackoverflow.com/questions/3454701...xt-files-from-a
http://superuser.com/questions/96060/windo...dbc-text-driver

У меня вся база хранится в одной большой таблице ("dxdb.csv" ) с суперпозицией полей для разных компонентов. Можно иметь несколько файлов CSV в данном каталоге, каждый из которых будет отдельной таблицей базы. Но мне удобнее хранить в одной таблице, ибо DxDatabook умный и при добавлении компонента на схему он свойсва с пустым значением не добавляет.

Уникальным полем у меня является "UID", которое по сути есть просто порядковый номер компонента. Поле PartNumber для связи с CL есть комбинация имени символа и имени посадочного места, которые замаплены в данном part.

Данный подход не является ни "правильным" ни "неправильным". Просто после доооолгих мытарств и изучения DxDatabook я для своего конкретного применения выбрал именно его.

Интересно, давно он так поумнел? Я точно не помню, конечно, но в 2005, вроде, они еще добавлялись...
А библиотек у Вас в DxDataBook тоже нет? Т.е. она всего одна?

Я работаю в EE7.9.2

Что значит фраза "А библиотек у Вас в DxDataBook тоже нет?"
DxDatabook - это просто механизм извлечения параметров для символа из внешей БД (через ODBC) при установке символа на схему. А также проверка и синхронизация параметров символов в схеме с внешней БД.

Т.е. собственно к DxDatabook относится только файл настроек .dbc.
Schema.ini относится к настройкам таблиц БД для Text ODBC driver.
Ну а CSV файл - это собственно сама БД, которая в общем случае ни к DxDatabook ни к ментору вообще отношения не имеет. Только поле PartNumber там присутствует для связи с CL. Если я добавлю поля с именем символа и именем посадочного места, то этот же самый CSV файл я смогу использовать в качестве библиотеки DBLib для Altium Designer.

Вот еще свою тестовую CL приаттачил - сейчас имеете все файлы для понимания как у меня это устроено.

За исклчением самого 7.9.2


Ну в окошке DxDatabook есть выбор библиотек. У Вас там сколько библиотек и каких?

Ну 7.9.2 известно где искать



Это не выбор библиотек, это выбор таблиц БД (хотя ментор для путаницы их обозвал "Library").
И да, там у меня только одна таблица под именем "dxdb" (см аттач).

Нормально обозвал. Всем, кто работает с САПР, это очень понятно. Но это не обязательно выбор таблиц. У меня, например, это вьюхи (запросы).


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

Это специально, потому что мне вести все типы компонентов в одной таблице гораздо удобнее. Я имею в виду добавление новых и правку старых компонентов в файле CSV с помощью LibreOffice Calc.
Сначала у меня и было несколько таблиц (файлов CSV), но попробовав хранить все в одной таблице, я увидел что для меня это гораздо удобнее.
Да, за это приходится платить пустыми полями в таблице, главное что в схему они не попадают, а потому добавление новых параметров есть тривиальным действием.

я извиняюсь, а почему выбран формат csv а не mdb какая нибудь? если можно в двух словах о преимуществах.
ну и еще office 2003 из csv не так интерпретирует ячейки типа -5/+5 % - он их вычисляет и получается -100.
опций как правильно импортировать почему-то не предлагает.
а при сохранении херит все кавычки. Как там с совместимостью MS office и Libre ofiice?

Ого! А как это он так получил -100?
У меня опенофис нормально открывает, и ексель 2000 тоже... Там при открытии надо обычно указывать тип колонок, тыкая на заголовки.

да легко
при открытии ничего не спрашивает.
"-" вначале ячейки считает за знак операции, дальше 5 делит на 5 это =1, = 100%, да минус впереди - вот -100 и получается.
попытка всосать как текст приводит к такому же результату, разве что еще разделители надо указать.
Если попытаться столбец сделать как текстовый - поздно, уже все посчитано на этапе всасывания.....

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

Полностью поджерживаю предыдущего оратора: текстовый формат есть вещь правильная и полезная для всего (особенно при теперешних скоростях машин). Не нужно усложнять то, что можно сделать проще и с таким же результатом. Вот поэтому с mdb и прочими DB не связывался, хотя немного потестит SQLite. Понятно, что, например, для корпоративной библиотеки нормальная БД может быть уместна, но обычно там пляшут от БД PLM. Просто для моих конкретных применений все эти сложности излишни.

Кстати, надо бы в список идей для DxDatabook добавить требование быстрой фильтрации списка компонентов. В Altium Designer такая вещь есть и она весьма удобна.

А что это такое?

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

to cioma
у вас в примере поле value текстовое. Как в этом случае с сортировкой по возрастанию/убыванию? и условиями больше-меньше?
Помнится было много копий сломано, что пле value должно быть вещественным причем двойной точности, иначе неправильно интепретировалось...
И если расширить вопрос, то с передачей на моделирование

виноват, нашел. было уже обсуждение http://electronix.ru/forum/index.php?showt...180#entry900100

https://mentor.brightidea.com



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

А для моделирования значение берется только из свойств символа, а как оно туда попало - вручную ввели, из PDB или из DxDB - значения не имеет.

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

Ну, тогда я двумя выстрелами одного зайца убил )

Сорри.
Ниасилил...

На Ваш вопрос "А что это такое?" я ответил ссылкой на brightideas, а вы спрашивали про фильтрацию. Но на этот вопрос я тоже ответил в том же посте. Потому два ответа (выстрела) и один заяц - Ваш изначальный порос

Это-то понятно, непонятно, как происходит фильтрация по нескольким полям сразу? Вот ввел я букву А. Допустим, она есть в нескольких строках, но в двух колонках. Как узнать, в какой колонке нашлась буква? Т.е. почему, в конечном счете результат фильтрации именно такой?

Потому что мне нужно как можно быстрее найти компонент. А быстрее получается когда кликнул мышкой в поле ввода, напечатал "100 Ohm" и из отфильтрованного списка выбрал нужный компонент. Так сделано в AD и это есть гут. В свою очередь в DxDB надо найти глазами правильно поле, кликнуть на него (2 раза?), ввести сроку и нажать ввод (или мышкой нажать на кнопку с воскл. знаком), а потом из отфильтрованного списка выбрать нужный компонент. Разница в количестве и сложности действий очевидна

Это понятно, но Вы не ответили на вопрос.

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

У меня есть база с парой тысяч компонентов и клиент. В клиенте я могу делать, что хочу, и там реализовано нечто подобное. Но поиск там ведется не по всем полям, а только по двум. Это наш внутренний партнамбер и партнамбер производителя.
Я не представляю, что было бы, если бы мы сделали поиск по всем полям сразу. Этих полей и значений там чуть ли не миллион.
Я как только ввел бы "100", появилась бы сотня компонентов, среди которых всего два резистора. Что же, потом среди найденного второй раз искать? Это тоже не выход.

Но вопрос правильный. Хотя, опять же, в моем случае уже есть деление на библиотеки, а это сильно помогает. Если мне надо искать именно 100 Ом, то я уже знаю, что Омы есть принадлежность резисторов, и я открываю резисторы. Потом ввожу в фильтр Value число 100.
Так что этот пример, видимо, более актуален для тех, у кого нет разделения на библиотеки.

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

Так одно другому не мешает. Можно и строку универсального поиска сделать и список SQL-запросов. Их даже можно объединить. Плюс регэкспы итп.
На данный момент к SupportNet доступа тоже не имею. Может кто, из имеющих доступ, закинет такую идейку (или две)?