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


У них как раз детали разбиты на категории, и в каждой категории свой набор полей для поиска.


Нет конечно. У меня другая специальность.


Мои познания в MySQL не позволяют прикинуть, как это реализовать на практике. Причём чтобы всем этим рулил сам пользователь через простой и понятный интерфейс, не хуже чем у экселя.

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

Всем привет! Решил выложить очередную версию. Не все обещанные изменения и дополнения присутсвуют, но я над ними продолжаю работать.
Из нового:
+Рядом с названием элемента теперь отображается иконка даташита, если он прикреплен.
+Просмотр даташита возможен и по двойному клику на иконке.
+Можно удалять ненужные типы корпусов в выпадающем списке.
+Появилась возможность скрывать и отображать столбцы.
+Выделение цветом элементов, количество которых меньше заданного.
+Редактирование путей на складе теперь из главного окна.
+Само редактирование категорий и путей теперь без дополнительного окна, прямо в дереве.
+Создание резервной копии базы при запуске программы.
+Убранны мелкие глюки

Из недоделанного:
- Кнопка удаления поставщика пока не работает.

P.S. Для правильной работы программы необходимо удалить Store.ini

ща заценим!

Извините, ayalon, но из-за недостатка времени вынужден уволиться из штата тестеров Вашей программы.

Gudd-Head и Секретный кот, всё что вы говорите, на мой взгляд, очень правильно. Позвольте подкинуть вам обоим одну идею. Не секрет, что программа нужна всего для двух операций - ввести то, что у нас есть, и потом когда-нибудь получить информацию о том, что мы ввели ранее, посредством удобного поиска. Все подобные программы, которые в изобилии плодят начинающие программисты, умирают из-за нечеловеческой трудоемкости первой операции, т.е. первоначального наполнения БД. Суть же моего предложения состоит в том, чтобы первоначально в БД закачать всю существующую номенклатуру с параметрами каждого элемента из доступных источников, а вам останется только указывать в этой БД количество и ссылки на ДШ только тех компонентов, которые у вас есть в наличии.

При поиске нетрудно будет организовать фильтр, чтобы выводились только те, у кого количество не равно 0.

И таким образом, соединить оба ваших, на первый взгляд, противоречивых пожелания - вести только номенклатурный учет (Секретный кот) и иметь возможность поиска по параметрам (Gudd-Head).

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

Где брать исходные данные для импорта в свою БД? Не знаю. У TI вся их номенклатура доступна для скачивания - вот, к примеру, логика: http://www.ti.com/lsds/ti/logic/gate-products.page
В формате экселя, но не вижу препятствий в экспорте из экселя в формат любой БД. При этом в скаченном файле уже понятна структура таблицы для хранения этих данных. Лишние поля можно выкинуть, и добавить только два поля - "Количество" и "Ссылка на ДШ" (ну, может еще "место хранения", "цена", в любом случае, это уже поля, содержимое которых зависит от пользователя и которые в любом случае заполняться должны будут самостоятельно).

Может, если хорошо пошакалить у других более-менее нормальных производителей, то тоже можно будет отыскать и прочие категории деталей для экспорта?

Вот, кстати, а здесь можно скачать родной екселевский файл с перечнем и параметрами 450-ти атмелевских контроллеров.

А здесь вот можно накачать екселевских файлов с параметрами диодов и выпрямительных, и Шотки, и мостиков, и мосфетов и т.д. от Semi.

И последнее. Уж коли речь зашла о кроссплатформенности, может имеет смысл вспомнить о и формате XML? Можно переварить с комфортной скоростью такой объем данных в этом формате, ни у кого подобного опыта не было?

Обнаружил глюк: при добавлении раздела вылет с ошибкой.
Исправление: удалить ini и заменить на этот файл

эээ... боюсь спросить... вы не обрабатываете исключения???

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

Идея очень верная. Проблема создать базу в тысячу раз сложнее, чем создать под нее программу.
Я попробовал качнуть Atmel-спецификацию со всеми характеристиками к себе в базу.
Все 500 компонентов мне не нужны. Это только захламление рабочей базы.
Поэтому сделал предварительный анализ и галками выбираю то что нужно. А если появится интерес всегда можно добавить.

Есть база компонентов в формате FDB, по заверениям авторов .....
На данный момент в справочнике:
биполярных транзисторов 12050 моделей;
полевых 34642;
IGBT 2787;
диодов 15549. Размер файла 29 метров с копейками.
Это о наполняемости БД....
Вопрос....как конвертировать в доступный формат, и каким инструментом это сделать?
Никогда не работал с таким форматом.

Формат FDB .Есть программа Extensis Portfolio, она такой формат поддерживает.

Вероятнее всего, это файл базы данных FireBird. Дельфийцы с ней любят работать.

Однако уже не так, есть клиент нативный для Linux. Платформа 1С 8.3

Хех, приветствую, коллеги-разработчики Я вот тоже тут на досуге занимаюсь программой для радиодеталей, только она скорее справочник, чем учетчик, хотя... "в нагрузку" планируется даже учет проектов. Будем глядеть на ваши наработки

п.с. С форматом FDB могу помочь если нужно, это как раз формат БД в моей программе

Вы вообще про моноширинные шрифты слыхали?
Тот же Courier или Lucida Console.

А можно посмотреть вашу программу?

Можно конечно. Только она в разработке еще.
Если Вас не смутит "недоделка", могу выложить где-то и в личку кинуть ссылку.

Внешний вид приблизительно такой:

Во, конкуренты подтянулись. Только вариант победит однозначно на платформе 1С82. 1С81 - умирает как мамонт.

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

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

Если вам, уважаемые разработчики, это чем-то поможет, то лично мне такая программа нужна для:
1. Пришел из магазина (или раздраконил на молекулы донора) и надо количество новых деталей внести в базу.
2. Захотел собрать чужую схему, начал комплектовать деталюхи. Надо узнать, что у меня есть из нужного, чем можно заменить то, чего нет, а что нужно докупить.
3. Начал разрабатывать схему, надо уточнить параметры того или иного компонента или подобрать по параметрам из того, что у меня есть.

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

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

Не смутит........Пожалуйста...

Вот я как раз и стараюсь сделать такую программу. Но именно функционал справочника а не просто склада приводит к некоторым "лишним" телодвижениям, без которых, увы, никак. Хотя бы внесение данных - типов элементов, типов корпусов, параметров... Главное - разработана достаточно универсальная структура БД, даже не знаю что еще можно туда добавить... Ну разве что планируються в будущем графики/диаграммы/спектрограммы... А встроенный редактор типа Визио (попроще конечно ) для чертежей корпусов - планируеться в обязательном порядке.

Раз такое дело, расскажу подробнее о своей разработке. Есть: классы деталек, по ним - типы. К типу привязаны - параметры, корпус, производитель, выводы (если не влом вводить, но зато потом, когда появятся чертежи корпусов - цоколевка будет смотреться одним кликом мыша), поставщики (с ценой). Отдельно единицы измерения (для параметров и т.п.). Отдельно - хранилище (склад) с наличием и номиналом деталей. Отдельно - проекты с деталями по ним. Ну не совсем отдельно, все взаимосвязано, например, можно будет сразу увидеть сколько чего есть для проекта, сколько не хватает, вплоть до печатных отчетов). Принципиальная функция заложенная в программу изначально - возможность простого и быстрого обмена данными между пользователями. Т.е. имеется у кого-то справочник чего-то там - он его выгрузил, другой юзер загрузил себе - и у него тоже есть эта информация. Ну и, конечно, будут (точнее уже есть в виде "написано как попало для себя") утилиты для автоматизации ввода данных (импорт из экселя/чего-то еще).

Использование как платформы 1С, я думаю, обосновано только для "склада". "Справочник" на нем сделать будет трудновато. Во всяком случае, полноценный справочник - не только из таблиц, но и с различной графикой. Хотя может я просто не знаю возможности новых 1С-ок