Управување со магацин - модел на податоци - функции - опрема; Материјал - подготвеност; Опстанок

Тоа сега може да се вклопи во парк или ИТ, но прво помислете дека областа за ИТ е подобра.
Ако ги разгледате форумите, се чини дека има потреба од електронско управување со магацинот, но се чини дека повеќето проекти заспиваат релативно брзо. Со OpenSource сè уште можете да пристапите до податоците и може да продолжите да работите со стариот софтвер некое време, со ClosedSource или апликации што повеќе не се одржуваат, макотрпно одржуваните бази на податоци се изгубени во одреден момент.
За мои сопствени цели работам на решение засновано на LAMP (Linux/Apache/mysql/PHP). Но, јас би сакал да ја дизајнирам основната база на податоци на таков начин што не само што одговара на мојот мал и среден проект, туку може да мапира и поголеми и помали проекти. Целта е да се дефинира структурата на базата на податоци што може да ја користат широк спектар на проекти - и што ги прави податоците преносливи. Секако е вклучен и API со основните функции.

Основни размислувања за базата на податоци:
- Способност на повеќе клиенти, т.е. неколку посебни продавници на една база на податоци. Од безбедносна гледна точка, особено со нашите теми, не со NonPlusUltra, бидејќи барем администраторот гледа сè, но исто така нуди можност за поставување на тест-кампови без нарушување на операцијата во живо. На крајот, тоа е само уште едно поле по табела
- EAN/GTIN итн. Треба да биде карактеристична карактеристика за сè што е зачувано. Соодветен број може да се генерира од слободни области за вашите сопствени производи (повторно полнење, само-варено, итн.).
- Категории (засновани на државните системи)
- Хиерархијата на складирање од локацијата за складирање-> полица-> ниво-> ред-> под-оддел треба да понуди доволно флексибилност за сите големини. Треба да бидат можни повеќе резервации на оддел за складирање (многу малкумина ќе го сторат тоа толку прецизно што ќе се додели посебен оддел за производ/датум за најдобар пред). За екстремистите, можете да додадете знаме што го контролира ова однесување.
- сè на UTF8 треба да биде доволно
- Способност за поставување ако секогаш ги составувате истите пакети. За мене, на пример, тоа би биле пакувања во вакуум со основна храна за една недела/една личност.

Лиценца итн.
- Код и структура на база на податоци под отворена лиценца, но сè уште не знам дали GPL, BSD или кој било друг е поевтин.
- Бидејќи добро одржуваните и бесплатни бази на податоци EAN се во недостиг, секако треба да се заврши рачна работа. Собраните податоци (EAN, име, нутриционистичка табела, задачи за категории) треба да бидат слободно разменливи и, доколку сакате, да бидат достапни за секого во собрана форма.

отворен за сите предлози - веќе напишав нешто слично во многу стара нишка - веројатно премногу стара.

Како прво, на вашиот проект му посакувам долг и исполнет живот!

Јас ги поделив моите предлози на двете компоненти „софтвер“ и „база на податоци“, така што ќе може лесно да се види каде ги лоцирам:

„Функција за преместување“ (кога прехранбениот производ е преместен од полицата X до Y; на пр., Поради простор)
Ако EAN се користи како клуч: генератор EAN (за ваши намирници; за да не мора да ги барате точните броеви од слободно достапниот базен и да избегнувате дупликати
Функција за пребарување на веќе регистрирани статии
Дупликат проверка
Ако е веќе способен за повеќе клиенти, тогаш исто така има (опционален) концепт за овластување.
РДА компјутер (можно е со неколку РДА, бидејќи секоја економска област, делумно секоја земја, има свои препораки)
Функција за увоз и извоз, доколку е потребно, алтернативно читливо од машина и читливо од човек

Јас не би го користел EAN како клуч, најмногу како едноставно поле за податоци (па дури ни како задолжително поле). Позадина: Јас не купувам секогаш намирници X од иста компанија (на пр. Затоа што Inzersd * rfer е во акција денес, а F * lix утре.) За мене, сепак, чили кон карне е во голема мера исто како и чили кон карн. Или печен грав од Хајнц, понекогаш со чили, понекогаш без. Разликите во хранливата вредност помеѓу две марки или сорти веројатно ќе бидат помали отколку помеѓу две домашно подготвени серии.
Способност за снимање на микро и макроелементи. (Содржина на протеини, маснотии, вода, јаглени хидрати и шеќер, минерали, витамини, елементи во трагови). И секако kcal/kJ.
Во прилог на грамови како единица тежина, вклучете и парчиња, порции (особено интересни за витамини) и литри.

LG, со среќа и да останеме моќ,

Работете како да живеете засекогаш. Loveубов како денес да умирате.

До базите на податоци EAN
Базата на податоци fddb има дури и API за надворешен пристап и е бесплатна.
https://fddb.info/api/v18/documentation/

[USER = "2997"] Мареси [/ USER] За жал, не е случај содржината на готови јадења да се разменува помеѓу различните производители.
Разликите во цените произлегуваат од различниот процент на вода или „ефтини калории“ како што се индустриски шеќер или жито.
За оние кои ги засноваат своите залихи на готови производи и „конзерви“, упатувањето на готовата база на податоци би било злато.

Јас ја користам базата на податоци FDDB преку проширувачот за планирање на диети. Тоа работи одлично.

Мислам дека целиот систем МОРА да остане офлајн. Значи, би било добро ако информациите „собрани“ за време на мирот, било да се од Fddb или од други извори, да се чуваат локално.

Пред неколку години во форумот презентирав „резервна база на податоци“. Не е вистинска апликација за ДБ, туку датотека во Excel. Во однос на функционалноста, тоа би било приближно минималното барање за нов систем за мене.

1. База на податоци за статии (проект за идентификација, имиња, цени, извори на набавка, хранлива вредност и дистрибуција на хранливи материи, категорија на написи, минимално ниво на залиха)
2. Управување со залихите со датум на складирање, локација на складирање, најдобро пред датумот, проект на ID
3. Автоматско креирање списоци за купување засновано на минималните нивоа на акции и/или MHD
4. Автоматски извештај за ставки со истечен рок на траење и со истекување
5. Лична база на податоци со возраст, пол, ниво на активност (за пресметка на потребите)
6. Пресметка на потребите и покриеност на достапната храна
7. Преглед на хранливи материи за складираната храна врз основа на препорачаната дистрибуција.

Кога би можел да програмирам, веројатно ќе го решив со база на податоци. За жал не можам. Никој не ме измами за тоа во Excel.

Убиј човек, ископај два гроба.

Но, целосна копија од базата на податоци FDDB не е неопходна за работа со базата на податоци.
Во „мирно време“, информациите од FDDB се повикуваат кога статијата е зачувана, а потоа се обработува, а добиените информации се зачувуваат локално. Ова во никој случај не е кршење на политиката за API.
Оваа ситуација за удобност не постои офлајн и мора да ја внесувате рачно.

Со оглед на тоа што во насловот „Модел на податоци“ се вели дека почнав да ситничам еден

производ
-------
Производ_ИД ИНТЕГЕР
Производ_NAM VARCHAR (50)
Product_TXT VARCHAR (255)

компонента
-----------
Компонента_ИД ИНТЕГЕР
Компонента_NAM VARCHAR (50)
Компонента_TXT VARCHAR (255)

единица
-------
Единица_ИД
Единица_NAM VARCHAR (50)
Unit_TXT VARCHAR (255)

Количина на состојки
----------------
Производ_ИД ИНТЕГЕР
Компонента_ИД ИНТЕГЕР
Количина_NUM ДЕЦИМАЛНИ (8,2)
Единица_ИД ИНТЕГЕР

производ
1 - гулаш - одличен гулаш од конзерва со мала чили нота

компонента
1 - калориска вредност
2 - белка од јајце
3 - јаглехидрати
4 - шеќер
5 - маснотии
6 - заситени масти
7 - влакна
8 - натриум
9 - витамин Ц.
10 - сол

единица
1 грам
2 проценти
3 - ккал

Количина на состојки
1 - 1 - 110 - 3
1 - 5 - 5,5 - 1
1 - 6 - 1,6 - 1
1 - 3 - 4,7 - 1
1 - 4 - 0,9 - 1
1 - 2 - 10 - 1
1 - 10 - 1,1 - 1

Она што сè уште недостасува, се разбира:
* Пакување/контејнер (конзерва, шише, стакло, хартија,.)
* Производител - евентуално може да биде дел од производот
* Набавка (зделка, датум, цена, број, попуст.)
* Локација на складирање - слободно дефинирана хиерархија. Стан - соба - полица - под - кутија - .
* Категорија (конзервирана храна, гарнир,.)
* Состојба (конзервирана храна, MRE, сурова, варена,.)
* Рецепти

Отворено
Најдобро пред. Ако купам 5 лименки со ист производ во истата продавница, сè уште можам да имам 5 урми најдобро пред датумот

Можам да мислам на уште 100 работи. но пред да размислам понатаму: оди ли ова во вистинската насока?