Форум РадиоКот

Доброго времени суток, уважаемые форумчане!

Не нашёл более подходящего раздела, поэтому пишу здесь.

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

Поиск подобных программ в Интернете удовлетворительных для меня результатов не дал. Были найдены либо слишком простые программы с примитивным функционалом, либо достаточно неплохие разработки, но не устраивающие меня по идеологии и интерфейсу. Поэтому я решил сделать свою программу, руководствуясь следующими принципами:
1) База данных (БД) не должна быть универсальным справочником, в котором "есть всё", т.е. данные о любом компоненте, какой только пожелаешь. Храниться должна только нужная пользователю информация об имеющихся у него в наличии компонентах (а также о тех, которые он планирует закупить). Пользователь сам заполняет свою базу исходя из того, какие сведения ему нужно хранить. Все остальные сведения - есть в Интернете.
2) В БД должна сохраняться информация о движении имущества (когда и откуда, и в каком количестве приходили какие-либо компоненты, куда отправлялись, на какие нужды расходовались), а количество имущества должно автоматически корректироваться в соответствии с указанными для него операциями движения. Такой подход упростит работу (отпадёт необходимость каждый раз вручную считать остатки, делать частые ревизии с целью установления фактического количества каждого компонента) и сведёт к минимуму возможные ошибки.
3) В БД должны также сохраняться другие сведения, которые могут быть полезны пользователю (тех. параметры компонентов, аналоги, корпуса и т.д.).
4) Данные должны храниться не только в текстовом, но и в графическом виде (изображения внешнего вида компонентов, цоколёвки и т.п.).
5) Программа должна иметь радиолюбительскую направленность, но никак не бухгалтерскую.
6) Программа должна иметь как можно более простой и удобный интерфейс.

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

Программа - бесплатная, поставляется "как есть", не содержит какого-либо вредоносного кода, не требует инсталляции, не делает записей в реестре Windows, не передаёт никакие данные в Интернет. Написана в среде разработки приложений Delphi 7. Совместима с любыми версиями ОС Windows - от ХР и выше, x32 / x64, системные требования - самые минимальные; единственное реальное условие - разрешение экрана: оно должно быть не менее 1024 х 768 точек (оптимальный вариант - 1920 х 1080). Формат таблиц с данными - MS Access (в случае особой необходимости допустима правка данных с помощью приложения Microsoft Access, однако такие действия, произведённые без знания структуры логических связей между таблицами, могут привести к ошибкам). К программе прилагается файл справки в виде документа Microsoft Word (не скучный, с картинками).

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

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

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

Программа, при относительной простоте интерфейса и принципов работы, всё же не так проста. Т.е. не рекомендуется начинать с ней работать "в лоб", "методом тыка", не имея представления об основных принципах и множестве различных её возможностей. Желательно хотя бы бегло просмотреть файл справки, а лучше - распечатать его, чтобы иметь всегда под рукой (да и читать с бумаги всегда проще).


Файлы БД.
Архив, который можно скачать по предлагаемой ссылке, имеет объём 105 Мб. В нём находятся следующие файлы, которые после распаковки должны находиться в одной папке:

- pr_ur.exe - исполняемый модуль программы.

- dbur.mdb - файл таблиц БД (формат таблиц - MS Access). Содержит демонстрационные данные, необходимые для изучения всех возможностей программы.

- dbur_1.mdb, dbur_2.mdb - файлы БД с частично заполненными таблицами. Используя любой из них, пользователь может не утруждать себя удалением демонстрационных данных из файла dbur.mdb, а сразу начать работу со своими данными "с чистого листа". Для использования надо удалить либо переместить в другое место файл dbur.mdb, а файл dbur_1.mdb (или dbur_2.mdb) переименовать в dbur_1.mdb. Использовать другое имя, отличное от " dbur.mdb", нельзя - исполняемый модуль в этом случае его "не увидит". Все манипуляции с удалением/переименованием необходимо производить, когда исполняемый модуль программы не запущен.
В обоих файлах основные таблицы пусты; оставлены только всегда актуальные данные - в таблицах "Страны", "Единицы измерения", "Технические параметры", "Корпуса", "Контрагенты" (только информация о производителях). Отличия между файлами: в dbur_1.mdb таблицы классификации заполнены, а в dbur_2.mdb они пусты. Т.е., взяв за основу файл dbur_1.mdb, пользователь может заполнять БД своими данными, используя как основу предоставленные пользователем данные и систему классификации компонентов; а при использовании файла dbur_2.mdb пользователь должен будет сам создать свою систему классификации компонентов.
ВАЖНО: при использовании в качестве базового файла dbur_2.mdb (т.е. того, в котором таблицы классификации пусты) пользователь должен перед первым запуском программы удалить либо переместить в другое место файл "items.txt", т.к. в нём содержится информация о классификации компонентов, и она будет загружена и в дерево классификации (только туда, но не в таблицы - они по-прежнему будут пусты).

- options.ini - файл, в котором хранятся настройки программы (в реестр Windows ничего не пишется, всё хранится только в этом файле). Поставляемый файл "_options.ini" содержит настройки под экран 1920х1080.
Если у пользователя именно такой монитор, он может использовать указанный файл,
для чего нужно переименовать его в "options.ini".

- Справка по программе.doc - краткая справка по программе для ознакомления с особенностями интерфейса и функциями программы.

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

- Папка "Docs" - хранилище даташитов компонентов.


Ограничения.
Автор программы не будет выкладывать исходный код программы. Это делается не потому, что текст программы представляет собой какой-то секрет (в нём нет ничего мудрёного, ибо автор - самоучка в этом деле), а во избежание появления "клонов" программы, обладающих другими (отличными от оригинала) свойствами, внешним видом и функционалом. При необходимости могу поделиться любыми фрагментами кода в качестве образца реализации некоторых функций, но не полным исходником.
Также следует отметить, что используемый в БД механизм доступа к данным весьма универсален и стабилен, т.е. программа должна работать на любом компьютере с ОС Windows. Тем не менее, на некоторых сборках (даже свеже-установленных!) Windows XP ("Звери" и т.п.) программа не запускалась ввиду отсутствия в сборке важных системных компонентов. Если вдруг такая проблема возникнет, решить её можно будет только установкой стандартной, "не урезанной", версии Windows.


Скачать.
Архив достаточно большой по размеру, т.к. в БД хранятся изображения.
Ссылка: https://cloud.mail.ru/public/FQjt/EhFoRtj34

Обсуждение, отзывы и пожелания - в этой ветке.

Например, вот: http://radiokot.ru/forum/viewtopic.php?f=24&t=1455

С ElemBase знаком, и даже кое-что перенял оттуда.
Но это как раз тот вариант, который, на мой взгляд, не хорош как по интерфейсу (основные данные раскиданы по разным окнам, нет изображений, возможности быстрого открытия даташитов и т.д.), так и по идеологии (БД содержит громадное количество сведений, бОльшая часть которых пользователю будет не нужна). Отсюда - громадное время загрузки данных. А зачем ждать, пока загрузятся данные, 99% которых пользователю не нужны? Я об этом писал автору программы, говорил, что интерфейс не оптимален. И в итоге сделал свой вариант, в котором постарался реализовать более удобный для работы интерфейс, а также принцип "нет хламу!" - пользователь сам заносит в свою БД только те данные, которые ему нужны.

а чего ты не использовал sqlite?
100мб как-то много для проги такой

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

С SQL Lite, быть может, было бы пошустрее, чем с ADO, но я с ним не работал, да и не хотелось возиться с инсталляторами и возможными проблемами, когда в документации одно, а в реальности несколько другое. Поэтому использовал уже проверенную технологию.
Модуль данных большой лишь по одной причине, я упоминал об этом выше - он содержит изображения. 105 Мб - это запакованная в архив информация, а в распакованном виде - почти 300 Мб. БД без изображений "весила" бы всего несколько Мб. Но без изображений - не интересно.

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

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

Понял, я не совсем в курсе, думал, что так. Хорошо, если всё просто.

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

Обновление.
Выкладываю обновление от 25.06.15. В архиве - исполняемый модуль программы (файл pr_ur.exe), который нужно просто скопировать в рабочую папку программы с заменой.
В обновлении исправлены существенные ошибки, а также сделаны мелкие доработки программы.
Ссылка: https://cloud.mail.ru/public/GRxk/8H78Ei1yg

Обновление базы данных от 20.07.2015 : https://cloud.mail.ru/public/8nXr/fLfEpu2WB
В архиве - три файла, которые нужно скопировать в рабочую папку программы с заменой (исполняемый файл программы + файлы хелпа в двух разных форматах).
Что нового:
1) Добавлена возможность упрощённого (из главного окна программы) ввода сведений об операциях движения имущества.
2) Исправлен ряд ошибок, интерфейс существенно доработан, в том числе расширились возможности выборки данных.
3) В соответствии с новыми возможностями доработан файл справки.

ничо так, приятненько. Под вайном захотело себе MS Jet 4.0.
честно, ms access - довольно таки дурацкий выбор. И блин, cp1251. Шел 2015 год...

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

под 1024 768 все огромное и кривое

ябнеюзал

Выбор механизма делался исходя из того, что я знаю. Я ж не дипломированный программист, а самоучка. Вообще, ADO неплохой механизм, но не шибко шустрый, особенно если в БД хранятся изображения, как в данном случае. Не исключено, что со временем будет сделан переход на другой движок.
Насчёт Code Page. Как я понимаю, данные в Access-овских таблицах хранятся в формате Unicode. Вставить данные в какое-либо поле БД из внешних источников можно без проблем, а вот в обратном направлении - возникают проблемы с "кракозябрами". Как это изменить, я не знаю.
Разрешение. На совсем мелких экранах информация в главном окне программы будет слишком сжата, это да. 1024х768 - это совсем мало. Такие мониторы сейчас не часто и встретишь. Замысел был такой - в главном окне одновременно показывать самую важную информацию о компоненте, в том числе его внешний вид, цоколёвку, параметры, место хранения и список операций движения, выполнявшихся с компонентами этого типа (когда и откуда, и сколько пришло, и сколько куда ушло). Это всё требует места в окне. Кстати, правая боковая панель - отключаемая, её можно скрывать, расширяя таким образом пространство основной таблицы. Да и размеры интерфейсных областей можно регулировать.
А по сложности... Какую версию тестили - изначально выложенную или с учётом последнего обновления? В последней версии существенно упрощён механизм ввода данных об операциях движения - теперь это можно делать прямо из главного окна программы. Кого пугает эта затея с движением имущества, для тех есть возможность прямого редактирования количества имущества (флажок в меню "Управление" + флажок в настройках). Что ещё тут сложного? Отдельные окна со справочными таблицами? Так места в главном окне и так не хватает, нельзя в нём разместить всю информацию. Был бы монитор 10.000х8.000 точек, тогда можно было бы всё в одном окне разместить. Реляционный (ссылочный) принцип? Так это в любой БД так делается, и не зря, такой подход имеет неоспоримые преимущества. Сложный интерфейс? Да вроде нет, я старался максимально всё упростить, этому вопросу уделялось первостепенное внимание, вот и горячие клавиши для этой цели придуманы. Сложным, пожалуй, можно назвать импорт из файлов спецификации, но эту возможность не всякий будет использовать... Пожалуй, главная сложность состоит в том, что никто не хочет читать хелп (да я и сам такой). Отсюда - непонимание принципов и незнание всех возможностей, заложенных в программу. Даже бегло пробежаться по файлу хелпа взглядом - уже можно выхватить полезные для себя моменты. И программа внезапно перестанет казаться сложной
Вообще, есть в сети простые однооконные решения с минимумом полей и примитивнейшим функционалом. Есть и сложные решения, elembase например. В обоих случаях предлагаемые базы данных меня не устраивали по функционалу, интерфейсу и идеологии. Например, elembase - это мега-справочник. Но зачем мне информация, скажем, о 10.000 транзисторов, если из этого массива мне понадобятся параметры одного-двух, а то и вовсе ничего не понадобится? Поэтому в данной БД принята другая концепция - каждый пользователь заносит в БД ту информацию, которая представляет для него интерес. Всё остальное уже есть в гига-мега-справочнике под названием "Интернет". Или зачем простейшая программа с примитивным функционалом? Такую БД и заполнять неудобно, и толку от неё почти ноль...

Guaho_150 писал(а): Я ж не дипломированный программист, а самоучка.

думаеш тут все илитные программисты что ли?
я вообще нихера не умею быдлокодить

Guaho_150 писал(а):Вообще, ADO неплохой механизм, но не шибко шустрый, особенно если в БД хранятся изображения, как в данном случае.

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

Guaho_150 писал(а):Такие мониторы сейчас не часто и встретишь.

у меня 24" и дело не в мониторе, ав масштабировании шрифтов и контролов при увеличении
виндовс это до сих пор не делает правильно в отличии от андроида и поэтому буквы мелкие или кривые
так что приходится сидеть на низком разрешении

Guaho_150 писал(а):Какую версию тестили - изначально выложенную или с учётом последнего обновления?

последнюю

Guaho_150 писал(а):Или зачем простейшая программа с примитивным функционалом? Такую БД и заполнять неудобно, и толку от неё почти ноль...

я пришел к выводу, что каждый хранит детали как попало и нет универсального решения
например у меня 4 шкафа с ящичками 4х8 + 1 внизу большой ящик
я бы запилил визуально и по цветам, чтобы быстро понимать, в каком шкафу и где примерно лежит
там конечно же будет и номер ящичка, но визуально можно нарисовать такой шкаф и выделить ячейку

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

Guaho_150 писал(а):Замысел был такой - в главном окне одновременно показывать самую важную информацию о компоненте

проблема в том, что самой важной информацией у вас считается ВСЕ) В распространенных erp справедливо принят другой подход: вот интерфейс управления ресурсами (==главное окно). Там - список собственно ресурсов с совсем уж основной информацией - артикул/id, наименование, количество общее или по складам, еще пара полей из предметной области. Подробная информация о каждом ресурсе выброшена на мороз перемещена в карточку ресурса, где тоже не лежит скопом, а организована по вкладкам/разделам соответственно ее характера - грубо говоря, характеристики/фоточки/даташиты отдельно, движение отдельно, места хранения отдельно. Да просто потому, что на практике вам никогда не требуются одновременно цоколевка, место хранения и график закупок. Иначе получается такой вот адъ.

kalobyte писал(а):зачем хранить изображения в бд?

почему бы и нет? человеческие субд вполне нормально работают с бинарными блобами.

kalobyte писал(а):и у тебя 3 файла бд

один. В комплекте три разные базы.

kalobyte писал(а):виндовс это до сих пор не делает правильно в отличии от андроида и поэтому буквы мелкие или кривые

винда это делает более-менее правильно. Андроид на большом мониторе произвольно масштабирует примерно так же.

arkhnchul писал(а):Да просто потому, что на практике вам никогда не требуются одновременно цоколевка, место хранения и график закупок. Иначе получается такой вот адъ.

Одновременно - не требуется, но одновременный показ - требуется, для того чтобы любые из этих данных могли быть быстро считаны. Тем более с учётом того, что эта информация не сама по себе существует, а привязана к выбранному пользователем компоненту. Зачем делать лишние клики для получения доступа к информации, если всё можно отобразить в главном окне? Только для того, чтобы иметь возможность работать на мониторах с разрешением 320х240 точек? При стандартном ноутбучном разрешении 1366×768 уже вполне можно работать с данной БД, без какого-либо напряга. Какой же это "адЪ", если интерфейс удобен?

Guaho_150 писал(а):Одновременно - не требуется, но одновременный показ - требуется

ненене девид блейн)

Guaho_150 писал(а):Зачем делать лишние клики для получения доступа к информации, если всё можно отобразить в главном окне? Только для того, чтобы иметь возможность работать на мониторах с разрешением 320х240 точек?

разрешение ни при чем. Разделение идет для предотвращения месива из информации и элементов управления из разных областей. Оно чисто логическое, а не "шоп влезло".

В видеомонтажной программе Adobe Premiere - от 6 и более (в зависимости от текущей задачи) интерфейсных областей, да ещё по несколько закладок в каждой, и никто почему-то не жалуется на "месиво информации". Интерфейс должен быть удобным - чем меньше кликов мышью и нажатий кнопок для доступа к информации, тем лучше.

Всем - доброго дня!
А, почему тема "заглохла"? Никому не интересно?!