Нужна идея по созданию БД для микро-склада
 

Приветствую, коллеги по разуму :)
Передо мной встала задача написать примитивную БД с одной интересной фишкой. Нужны идеи.

Мы имеем: микро-склад с несколькими группами вещей.
Группы вещей такие как: картриджи, тонер, бумага, ручки и т.д. Всего порядка 8-10 групп.
В каждой группе от 1 до 20-30 конкретных позиций. Например, картриджи включают в себя "картридж HP 79А", "картридж HP 285А" и т.д.

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

Свои идеи: на 90% уверен, что будет использоваться ручной сканер, типа как в супер-маркетах (и много где ещё). Пикнул по вещи, она сразу же отобразилась в программе и подтвердил отпуск.
Сканеры стоят от 1000 руб, что нас очень устраивает.

Проблема: не все (я бы сказал ДАЛЕКО не все) товары имеют свой заводской штрих-код. Картриджи, тонер - это да. Но есть много ручек, которые без упаковок. Есть разные финтифлюшки, которых куча, а штрих-кода нет.
То есть нужно как-то генерировать СВОЙ штрих-код.

Вопрос: как правильно реализовать генерацию штрих-кода?
В идеале нужно реализовать такой ход: на склад привозится товар, на всё генерируется штрих-код на любом адекватном сайте (важно!), далее всё как-то забивается в базу и потом идёт отпуск товара по необходимости.

Поясню пару моментов.
Почему хочу генерировать штрих-код на стороннем ресурсе? Потому что своих программистов не предусмотрено, а я (как самый прошаренный в офисе) знаю самые-самые азы Delphi 7 (олдскул мастер, да).
Т.е. сам я в свою прогу вряд ли встрою генератор штрих-кода. Очень вряд ли. Скажем так, это я делаю как хобби (за это не платят) и сильно заморачиваться не хочу.

У меня уже есть своя реализованная микро-БД, которая включает в себя всё описанное выше, но поиск позиции осуществляется вручную. В поисковую строку вбивается что-то типа "ручка" и на экране отображаются все строки, включающие в себя эту часть. Далее выбирается нужная строка и идёт отпуск товара.

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

Можете подсказать, как реализовать подобную схемы? Или, может, есть другие варианты?
Суть: изначально внести в базу товар вручную, затем ОЧЕНЬ БЫСТРО его находить и вычитать из базы.
Саму базу я сделаю, нужен механизм отпуска.

П.С. Это НЕ магазин, т.е. каких-то супер надёжных или молниеносных решений не надо. Это склад внутри офиса с отпуском вещей в сам офис.
Просто хочется немного облегчить работу завхозу. И чуток пошевелить мозгами.

Мда. Судя по всему разделу БД (дальше не смотрел), форум просто "кишит" программистами и иже с ними.
Нафига, спрашивается, несколько отдельных разделов для программирования? Коллекционировать темы с "0" ответов?

Скажи, какой Ктулху запрещает тебе набрать в гугле https://www.google.ru/search?q=%D0%B...C8H6sAGNiZGQCw

если в ваших интернетах принято сразу на "ты", тогда ок.

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

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

Впрочем пишется слитно...
Для тех, кто НЕ умеет читать:
Это всё по данной мною ссылке.
Не нравится? Чем?
ТЗ не вижу, вижу лёгкое фантазирование на тему... И вижу недовольство тем, что ещё не выстроилась очередь желающих бесплатно помочь.

В MS Access проблемы генерации уникального кода не стоит - есть такой тип переменной "Счетчик". который в автомате генерирует уникальное число. Можно написать функцию, которая будет его "упаковывать/распакоывать" в цифро-буквенную комбинацию. Кстати, задача достаточно просто решается на этой СУБД, но нужны знания и опыт. Проще заказать это специалисту. От Вас - конкретизация ТЗ.
Еще один совет - т.к. аппетит приходит во время еды, у Вашего руководства очень быстро появятся необходимость в комплексной автоматизации торговли и привязки её к бухучету. В связи с этим рекомендую рассмотреть возможность приобретения типовой конфигурации 1С "Управление торговлей". Там все эти (и не только эти) функции уже реализованы.

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

на счёт генераторов штрих-кода и т.п.
да, ТЗ нет, но на данном этапе оно и не нужно. я же не прошу дать мне готовую программу или исходники оной.
сейчас меня интересует именно идея.

например, вот одна из возникших проблем, которую хочется решить на начальном этапе.
допустим, закупили 50 пачек офисной бумаге по 200 рублей. спустя месяц закупили ещё 30 пачек по 190 рублей.

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

вопрос 2: если штрих-коды будут разные для закупок или для каждой пачки, то как потом отследить расход бумаги в целом? если это будет не одна позиция с расходом 20-40-60 пачек, а 2 или более позиций.
если же штрих-код будет один на всю бумагу, то как отследить, какая расходуется - дорогая или дешёвая?

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

Николай_С, использование сторонних программ не подходит, т.к. позиция руководства: "нам пофиг".
дело в том, что я (обычный сотрудник) делаю прогу для другого обычного сотрудника. руководству фиолетово, их устраивает ведение учёта на бумаге. благо, как я писал выше, объёмы небольшие. один человек конспектирует приход/расход легко.

просто я решил сам размять мозг чисто для себя. с пользой для людей. потому и решил стать некрофилом и откопать Дельфи 7 :) ну и написать прогу.
не взлетит - и ладно. но попробовать хочется.

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

Альтруизм нынче не в ходу, учтите это при внедрении вашей программы.

Нет, Алексей, не так!
Уникальный штрих-код генерируется только для каждой номенклатурной единицы товара (например, бумага Светокопи, 80 г*м, 500 л). Делается это отдельным полем в справочнике "Номенклотура". А вот учет партий товара делается в таблицах "приход-расход" тоже отдельным полем. Иначе невозможно потом будет отследить к какой партии относится данный товар (если это необходимо). На сам товар, в зависимости от необходимости, клеется тот, или иной (а чаще оба, но они должны иметь свой опознавательный знак) штрих-код.

Что касается выбора платформы, я бы настоятельно рекомендовал Access. Изучается быстро, удобен для быстрой реализации подобных задач, имеет готовые шаблоны форм и мастера их создания. С Делфи протавокаетесь гораздо дольше.

Я бы взялся за реализацию подобной задачи не за один килорубль, и даже не за 10. Готовое решение обойдется на несколько порядков дешевле. ;)
Но, если хочется самому попробовать свои силы, отговаривать не стану - дерзайте. Если что - спрашивайте.

А ты сам на ней писал? ;)

При проверке своего поста тоже вижу свои ошибки (например, в слове "номенклатура"). Прошу меня извинить, пишу с планшета.

Андрей, я почти 10 лет своей жизни занимался исключительно программированием, в частности 3 года - разработкой первичных учтеных систем. :)
Был у меня коллега (страстный поклонник Делфи), который спорил, что на Делйи он напишет лучше. Я ему дал задание сделать функцию по переводу числовой денежной суммы в строковую в VBA. Он написал её за один день и больше со мной не спорил.

Коля, я спросил: писал ли ты именно на Delphi?
Я работал и писал на ней, с Access только работал, поэтому хочется знать твою квалификацию в обеих системах.
P.S. Моё мнение по работе: Access намного более тормозной и жрущий ресурсы, как, впрочем, большинство поделок мелкомягких.

Сам лично в Делфи я ничего не писал. Вышеупомянутый коллега ввёл меня в курс по Делфи. Моё мнение: Делфи - мощный и удобный инструмент для написания законченных приложений. Имеется обширный и удобный инструмент для создания и работы с уже имеющимися БД. Но по сравнению с Access достаточно громоздок и неудобен для реализации быстрых задач, а также задач, требующих постоянной доработки.
Правильно спроектированная БД в Access работает без сбоев и мгновенно даже с большим объемом инфы и на старой технике. Если нужно еще быстрей, таблицы переносятся в MS SQL. Работы на час с перекуром.

Delphi 3 работала с Sybase DB-lib или CT-lib и Interbase SQL-link. Потом добавились другие форматы. Организовывалось всё очень легко и удобно. BDE - очень удобный инструмент для развёртывания баз.
Мой начальник написал программку, показал главному инженеру, тот сказал: завтра она должна стоять на 11 рабочих местах.
Я отматерил шефа, скачал InstallShield Wizard, поставил себе, изучил и сделал инсталляшку, попутно поправив некоторые мелкие проблемы в программе. На это ушло около трёх часов. Потом за два часа установил на всех рабочих местах. И на следующее утро люди перешли с клитора на новую программу с сетевыми базами ;)

К достоинствам Access можно отнести возможность одновременного конструирования и работы с БД и приложением. Правда тут имеется одна тонкость - таблицы д.б. в одном файле, а остальное приложение - в другом. Такая конструкция позволяет быстро масштабировать БД, переведя её на Interbase или MS SQL.
Инструмент работы с данными в Access весьма скромный, но удобный. Особенно порадовал графический интерфейс реляции (точно такой же у MS SQL). Мастера создания форм тоже очень удобные. Для начального развития - самое то.
Единственный существенный недостаток Access - невозможность создания законченного приложения. Вернее, это возможно, но стоит очень дорого. В этом весь Microsoft.

Попробуйте вместо Delphi или Access использовать мой велосипед для создания БД
Простая визуальная среда разработки баз данных - My Visual DataBase

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

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


также пишу книгу как с нуля создавать приложения и БД
Пишу книгу о базах данных (Page 1) — Russian — My Visual Database

Почитал Вашу книжку.
Сразу несколько вопросов:
- Зачем вводить новую единицу "сущность"? Ни разу нигде её не встречал и не вижу смысла для её введения. Старайтесь придерживаться общепринятой аббревиатуры.
- Зачем разделять дату и время? В подавляющем большинстве случаев используется отсчет от определенной даты, а в поле хранится смещение. И еще, "денежный" - это формат числового поля, а не тип данных.

Дальше типа данных я не читал, а бегло просматривал. Первый раз вижу СУБД, описание которой удалось разместить на 57 страницах стандартного шрифта. Я-то изучал MS Access по переведенной книге от разработчика, состоящей более чем из 500 страниц. ;)
А можно поподробнее рассказать про формат файла .vdb? Возможно ли к нему подключиться (хотя бы через ODBC) и использовать в многопользовательском режиме?

Николай_С

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

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


На счет разделения даты и времени не понял, в различных СУБД обычно присутствуют такие типы данных как ВРЕМЯ, ДАТА, ВРЕМЯ И ДАТА. По поводу смещения к сожалению также не понял.


Тип данных как Денежный например присутствует в некоторых СУБД, в т.ч. MS Access.


Книгу я только начал писать, и с ней предстоит еще много работы.


Файл .vdb несет в себе только имя проекта и его версию, по сути это просто ini файл, к нему нельзя подключиться.


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

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

Здается - от слова здание?
Слыхал о программе бизнеспак?
Нарисовать можно всё. Тут с год назад QR на гараже мелом нарисовали. Пацаны ради смеху отсканили - прошло!

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

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

В бизнес-Паке не отражается "черный нал"