1. С каким маршрутом разработки ПП Вы работаете

[cioma 0]

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

 

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

[vitan 2]

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

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

 

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

[AlexN 0]

to cioma

у вас в примере поле value текстовое. Как в этом случае с сортировкой по возрастанию/убыванию? и условиями больше-меньше?

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

И если расширить вопрос, то с передачей на моделирование

 

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

[cioma 0]

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

 

https://mentor.brightidea.com

 

to cioma

у вас в примере поле value текстовое. Как в этом случае с сортировкой по возрастанию/убыванию? и условиями больше-меньше?

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

И если расширить вопрос, то с передачей на моделирование

 

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

 

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

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

 

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

[vitan 2]

https://mentor.brightidea.com

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

[cioma 0]

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

[vitan 2]

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

Сорри.

Ниасилил...

[cioma 0]

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

[vitan 2]

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

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

 

[cioma 0]

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

[vitan 2]

Потому что мне нужно как можно быстрее найти компонент.

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

 

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

 

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

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

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

 

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

Так что этот пример, видимо, более актуален для тех, у кого нет разделения на библиотеки.

 

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

[cioma 0]

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

На данный момент к SupportNet доступа тоже не имею. Может кто, из имеющих доступ, закинет такую идейку (или две)?