Программа для учёта деталей

@kypps · Регистрация: 13.02.2010

Студворк — интернет-сервис помощи студентам

Всем доброго времени суток!
Подскажите пожалуйста кто нибудь простенькую программу.Что нибудь вроде базы данных для радиодеталей.Чтобы не рыться в коробках и по полкам,а то за год накопилось разнообразие нереализованных деталей и в голове уже всё не помещается))

@tid_fom · 06.10.2012, 01:56

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

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

@tid_fom · 06.10.2012, 01:58

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

@sitimur · 06.10.2012, 13:58

Сообщение от oyotom

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

По поводу упрощения вставки картинок, придумал себе сделать так: в гугле есть поиск картинок по имени, например вот ссылка https://www.google.ru/seorsh?q=Atmega12 ... 20&bih=975
После получения ответной страницы, можно пропарсить страницу, и пользователю предложить наиболее подходящую картинку :-)

@tid_fom · 06.10.2012, 19:22

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

@oim · 07.10.2012, 00:32

Сообщение от oyotom

Месяц назад написал для себя программу, которую назвал Лагерхаус (по-немецки - Склад). Базу данных заполнил немного, по-тихоньку буду продолжать наполнять её, в том числе дорисую недостающие иконки компонентов.

В качестве предложения:
Сделать одну таблицу с типами компонентов с полями: id, типа компонентов, остальные таблицы слить в одну добавив поле с типом компонентов.

Далее просто накладывать фильтр по типу компонента.

07.10.2012, 00:43

Сообщение от oim

В качестве предложения:
Сделать одну таблицу с типами компонентов с полями: id, типа компонентов, остальные таблицы слить в одну добавив поле с типом компонентов.
Далее просто накладывать фильтр по типу компонента.

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

Проще иметь несколько таблиц, оптимизированных под разные типы компонентов. Разделив даже, например, полевые транзисторы и обычные. А то и отделив еще мощные от маломощных.

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

@tid_fom · 07.10.2012, 00:53

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

@oim · 07.10.2012, 01:45

В данной программе все таблицы имеют одинаковую структуру, где и заносятся все параметры по компонентам. Один компонент - одна запись. Что повлечет проблемы с увеличением функционала программы.
Отдельной таблицы с количеством, местом хранения, ценой и т.д. нет. Поэтому и предложил слить все в одну таблицу.
Тем более, что sqlite все едино, что 10 таблиц по 1000 строк, что 1 таблица на 10000. А таблиц с миллионами строк, насколько я понимаю, не предвидится.

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

@tid_fom · 07.10.2012, 01:55

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

(можно попросить исходники в личку? обещаю никому не отдавать.)

@tid_fom · 07.10.2012, 01:56

Сообщение от oim

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

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

@oim · 07.10.2012, 02:14

Некоторые мысли по поводу структуры БД подобных программ. А именно - учет компонентов.
Мне кажется, что для данного класса задач лучше подойдут noSQL БД. Ибо компоненты даже в одном классе (транзисторы, конденсаторы, даже резисторы, не говоря про ИС) могут иметь разные наборы параметров. Вот и приходится в случае SQL модели для каждого случая или заводить отдельные таблицы или вводить дополнительные поля в существующих таблицах.

БД noSQL в свете текущей задачи избавлены от этого недостатка. Простейший пример noSQL БД - XML файлы. Скорость работы такой БД оставим за кадром.

@oim · 07.10.2012, 02:15

Сообщение от tid_fom

Сообщение от oim

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

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

Сообщение от tid_fom

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

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

@tid_fom · 07.10.2012, 02:18

Сообщение от oim

Простейший пример noSQL БД - XML файлы. Скорость работы такой БД оставим за кадром.

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

@oyotom · 07.10.2012, 23:44

Пофиксил всё что можно, теперь программа летает, и базе данных не страшна нагрузка, удар держит.
Мне по-прежнему нужно ваше тестирование. Кстати, вывел визуальное обозрение количества элементов в левый список элементов. И в разделе "Подробнее о элементе" если нажать на + или минус, то происходит автообновление количества в левой колонке списка элементов.

http://i065.***********/1210/bf/fd2f4df46fe4.jpg

@tid_fom · 07.10.2012, 23:47

качать обновленную версию где?

@oyotom · 07.10.2012, 23:50

Сообщение от tid_fom

качать обновленную версию где?

http://файлообменник.рф/02f0fnuxbz3p.html

@tid_fom · 08.10.2012, 00:39

не. пасибо. перезалей плиз на ргхост. а то у меня с этого стабильно не качается.

@oyotom · 08.10.2012, 00:42

ргхост вообше мёртвый. 3 раза закачивал

@tid_fom · 08.10.2012, 00:53

не хочет качаться с этого файлообменника, и хоть стреляйся.

@oim · 08.10.2012, 01:25

http://rghost.ru/40822151 - зеркало. Но через месяц умрет. Если надо, могу положить надолго.

Новые блоги и статьи Все статьи Все блоги /
сукцессия 33. открытые вопросы от клауде anaschu 19.07.2026 "Что накопилось за эту часть А — тринадцать правок, из которых шесть пришли из ваших вопросов и каждая оказалась реальной ошибкой, а не калибровкой: односторонний симбиоз, отсутствующий листопад,. . .	32 сукцессия anaschu 19.07.2026 сукцессия 28‑мерное ядро стабилизировано Коллеги, фиксирую разбор инженерных правок и их изоморфную проекцию на экономику, меметику и половой отбор. Модель теперь не «подкручивает» сходимость —. . .	сукцессия 31: модель микоризы - это модель ещё нескольких явлений, социальных и экономических anaschu 18.07.2026 Теория «Всего»: апдейт v1. 1. 2 — 28‑мерное ядро стабилизировано Коллеги, фиксирую разбор инженерных правок и их изоморфную проекцию на экономику, меметику и половой отбор. Модель теперь не. . .	сукцессия 30. Массив проверяющих друг друга моделей anaschu 18.07.2026 Архитектура сети взаимопроверяющих моделей микоризной сукцессии (v2. 0) Развитие тензорного ОДУ-ядра и создание кросс-платформенного калибровочного полигона Уважаемые коллеги! В продолжение. . .
Грибы - это женщины, деревья - это мужчины. Анти инь янь для союза мужчины и женщины. anaschu 18.07.2026 ГЛАВНЫЙ НАУЧНО-ФИЛОСОФСКИЙ ВЫВОД: Сексуально-Репродуктивный Капитализм против Государства Моногамии Коллеги, мы вышли на финишную прямую 20-мерного ОДУ-моделирования вековой сукцессии (ветка. . .	Текстовый слайдер с нумерацией страниц и кроссбраузерность. russiannick 18.07.2026 Один мой друг написал текстовый слайдер с нумерацией страниц. Сегодня я расскажу как он умудрился подружить его с кроссбраузерностью. Очевидно сложно угодить с шириной каждому браузеру. Один крадет. . .	Грибы - это мемы, дерево - это человек. Применение микоризной модели к теории меметики Докинза. anaschu 18.07.2026 Меметический изоморфизм теории «всего»: Грибная сукцессия как модель эволюции идей Докинза Базовый код системы ОДУ микоризной сукцессии описывает не просто биологию, а универсальную. . .	Грибы - это корпорации, деревья - это государства. Механизм массонского захвата власти anaschu 18.07.2026 Макроэкономический изоморфизм теории «всего»: Грибная сукцессия как модель транснационального капитализма Базовый код системы ОДУ микоризной сукцессии описывает не просто биологию, а. . .

@kypps 0 / 0 / 0 Регистрация: 13.02.2010 Сообщений: 27

	Программа для учёта деталей 18.02.2010, 00:26. Показов 224136. Ответов 294 Метки нет (Все метки) Всем доброго времени суток! Подскажите пожалуйста кто нибудь простенькую программу.Что нибудь вроде базы данных для радиодеталей.Чтобы не рыться в коробках и по полкам,а то за год накопилось разнообразие нереализованных деталей и в голове уже всё не помещается)) 0

@tid_fom 0 / 0 / 0 Регистрация: 21.10.2011 Сообщений: 1,860
	06.10.2012, 01:56
	а это и есть домашняя. да и что есть "дофигища"? понятно, что не пара десятков. сейчас (и далеко не все забито) транзисторов - почти сотня позиций, диодов - полсотни, пара сотен микрух, ну и всякого-разного сотня-другая позиций. как выглядит, признаться, держать в базе нет необходимости - протянул руку, и посмотрел. а место хранения - очень важно. вон та колонка "место" - это оно и есть. ах да. еще весьма критичное пожелание - разный набор полей для разных типов. например для полевиков набор я показал, для диодов - прямое напряжение, падение, время, для всяких микросхем, по идее, достаточно и просто текстового комментария. с обязательной возможностью сортировки по той или иной колонке для быстрого подбора. 0

@tid_fom 0 / 0 / 0 Регистрация: 21.10.2011 Сообщений: 1,860
	06.10.2012, 01:58
	и да. каталог мне не надо. при необходимости есть маусер, диджикей, етц. но в домашней базе иметь перед глазами основные параметры имеющейся комплектухи - чертовски удобно. 0

@tid_fom 0 / 0 / 0 Регистрация: 21.10.2011 Сообщений: 1,860
	06.10.2012, 19:22
	может, прикрутить парсер каталогов маусера и диджикея? там обычно и картинки есть, и основные параметры. 0

@tid_fom 0 / 0 / 0 Регистрация: 21.10.2011 Сообщений: 1,860
	07.10.2012, 00:53
	да, поддерживаю. под каждый тип деталек нужна своя таблица со своим набором характерных полей. в этом плане классические БД очень удобны. вынес общие в основную (ключ, наименование, количество, место хранения, цена), а остальные уже по ключу в ту или иную таблицу смотрят и отображаются при необходимости. 0

@oim 0 / 0 / 0 Регистрация: 05.03.2012 Сообщений: 71
	07.10.2012, 01:45
	В данной программе все таблицы имеют одинаковую структуру, где и заносятся все параметры по компонентам. Один компонент - одна запись. Что повлечет проблемы с увеличением функционала программы. Отдельной таблицы с количеством, местом хранения, ценой и т.д. нет. Поэтому и предложил слить все в одну таблицу. Тем более, что sqlite все едино, что 10 таблиц по 1000 строк, что 1 таблица на 10000. А таблиц с миллионами строк, насколько я понимаю, не предвидится. Еще замечание. Хранение фотографий компонентов, их схем или описаний в одном не структурированном каталоге вызовет тормоза файловой системы при наличии в оном нескльких тысяч фалов. 0

@tid_fom 0 / 0 / 0 Регистрация: 21.10.2011 Сообщений: 1,860
	07.10.2012, 01:55
	просто тогда придется фильтровать выдачу в зависимости от компонента. что бОльшие тормоза, чем несколько таблиц. (можно попросить исходники в личку? обещаю никому не отдавать.) 0

@oim 0 / 0 / 0 Регистрация: 05.03.2012 Сообщений: 71
	07.10.2012, 02:14
	Некоторые мысли по поводу структуры БД подобных программ. А именно - учет компонентов. Мне кажется, что для данного класса задач лучше подойдут noSQL БД. Ибо компоненты даже в одном классе (транзисторы, конденсаторы, даже резисторы, не говоря про ИС) могут иметь разные наборы параметров. Вот и приходится в случае SQL модели для каждого случая или заводить отдельные таблицы или вводить дополнительные поля в существующих таблицах. БД noSQL в свете текущей задачи избавлены от этого недостатка. Простейший пример noSQL БД - XML файлы. Скорость работы такой БД оставим за кадром. 0

@oyotom 0 / 0 / 0 Регистрация: 18.07.2012 Сообщений: 36
	07.10.2012, 23:44
	Пофиксил всё что можно, теперь программа летает, и базе данных не страшна нагрузка, удар держит. Мне по-прежнему нужно ваше тестирование. Кстати, вывел визуальное обозрение количества элементов в левый список элементов. И в разделе "Подробнее о элементе" если нажать на + или минус, то происходит автообновление количества в левой колонке списка элементов. http://i065.***********/1210/bf/fd2f4df46fe4.jpg 0

@tid_fom 0 / 0 / 0 Регистрация: 21.10.2011 Сообщений: 1,860
	07.10.2012, 23:47
	качать обновленную версию где? 0

@tid_fom 0 / 0 / 0 Регистрация: 21.10.2011 Сообщений: 1,860
	08.10.2012, 00:39
	не. пасибо. перезалей плиз на ргхост. а то у меня с этого стабильно не качается. 0

@oyotom 0 / 0 / 0 Регистрация: 18.07.2012 Сообщений: 36
	08.10.2012, 00:42
	ргхост вообше мёртвый. 3 раза закачивал 0

@tid_fom 0 / 0 / 0 Регистрация: 21.10.2011 Сообщений: 1,860
	08.10.2012, 00:53
	не хочет качаться с этого файлообменника, и хоть стреляйся. 0

@oim 0 / 0 / 0 Регистрация: 05.03.2012 Сообщений: 71
	08.10.2012, 01:25
	http://rghost.ru/40822151 - зеркало. Но через месяц умрет. Если надо, могу положить надолго. 0