Управление на складове - модел на данни - функции - оборудване; Материал - Готовност; Оцеляване

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

данни

Основни съображения относно базата данни:
- Възможност за много клиенти, т.е. няколко отделни склада в една база данни. От гледна точка на сигурността, особено с нашите теми, а не с NonPlusUltra, тъй като поне администраторът вижда всичко, но също така предлага възможност за създаване на тестови лагери, без да се нарушава работата на живо. В крайна сметка това е само още едно поле на таблица
- EAN/GTIN и т.н. трябва да бъдат отличителната черта на всичко съхранявано. Съответно число може да се генерира от свободни площи за вашите собствени продукти (презаредени, само сварени и т.н.).
- Категории (базирани на държавните системи)
- Йерархията за съхранение от място за съхранение-> рафт-> ниво-> ред-> под-отделение трябва да предлага достатъчно гъвкавост за всички размери. Трябва да са възможни множество резервации в отделение за съхранение (много малко хора ще направят това толкова точно, че да се отдели отделно отделение за всеки продукт/най-добрата дата). За екстремистите можете да добавите флаг, който контролира това поведение.
- всичко на UTF8 трябва да е достатъчно
- SET способност, ако винаги сглобявате едни и същи пакети. За мен например това биха били опаковани с вакуум пакети с основна храна за една седмица/един човек.

Лиценз и т.н.
- Структура на кода и базата данни с отворен лиценз, но все още не знам дали GPL, BSD или която и да е друга е по-евтина.
- Тъй като добре поддържаните и безплатни бази данни на EAN са по-скоро дефицитни, със сигурност има ръчна работа. Събраните данни (EAN, име, хранителна таблица, присвояване на категории) трябва да бъдат свободно заменяеми и при желание да бъдат достъпни за всички в събрана форма.

отворен за всички предложения - Вече написах нещо подобно в много стара тема - вероятно твърде стара.

На първо място, пожелавам на вашия проект дълъг и пълноценен живот!

Разделих предложенията си на двата компонента „софтуер“ и „база данни“, така че да е лесно да се види къде ги намирам:

  • „Функция за преместване“ (когато даден хранителен артикул е преместен от пространството на рафта X в Y; напр. Поради съображения за пространство)
  • Ако EAN се използва като ключ: EAN генератор (за вашите собствени хранителни стоки; за да не се налага да търсите правилните номера от свободно достъпния басейн и да избягвате дублирания
  • Функция за търсене на вече регистрирани статии
  • Дублирана проверка
  • Ако вече е с възможност за множество клиенти, тогава също и с (по избор) концепция за оторизация.
  • RDA компютър (вероятно с няколко RDA, тъй като всяка икономическа област, отчасти всяка страна, има свои собствени препоръки)
  • Функция за импортиране и експортиране, ако е необходимо, алтернативно машинно четима и четена от човека

  • Не бих използвал EAN като ключ, най-много като просто поле за данни (и дори не като задължително поле). Предистория: Не винаги купувам хранителни стоки X от една и съща компания (например, защото Inzersd * rfer е в действие днес, а F * lix утре.). За мен обаче чили кон карне е до голяма степен същото като чили кон карне. Или запечения боб на Хайнц, понякога с лют пипер, понякога без. Разликите в хранителната стойност между две марки или сортове вероятно са по-малки, отколкото между две домашно приготвени партиди.
  • Възможност за записване на микро и макронутриенти. (Съдържание на протеини, мазнини, вода, въглехидрати и захар, минерали, витамини, микроелементи). И разбира се kcal/kJ.
  • В допълнение към грамовете като единица тегло, включвайте също парчета, порции (особено интересни за витамините) и литри.

LG, късмет и оставаща сила,

Работете така, сякаш живеете вечно. Обичайте така, сякаш ще умрете днес.

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

[ПОТРЕБИТЕЛ = "2997"] Maresi [/ ПОТРЕБИТЕЛ] За съжаление просто не е така, че съдържанието на готови ястия е заменяемо между различните производители.
Разликите в цените се дължат на различното съотношение на водата или „евтините калории“ като промишлена захар или зърно.
За тези, които базират запасите си на готови продукти и „консерви“, препратката към готова база данни би струвала злато.

Използвам базата данни FDDB чрез удължителя за планиране на диета. Това работи чудесно.

Мисля, че цялата система ТРЯБВА да остане офлайн. Така че би било добре информацията, „събрана“ по време на мирно време, било то от fddb или други източници, да се съхранява локално.

Преди няколко години представих "резервна база данни" тук във форума. Не истинско DB приложение обаче, а файл на Excel. По отношение на функционалността, това би било приблизително минималното изискване за нова система за мен.

1. База данни за артикули (идентификационен номер на артикул, имена, цени, източници на доставка, хранителна стойност и разпределение на хранителните вещества, категория на артикула, минимално ниво на запасите)
2. Управление на запасите с дата на съхранение, място на съхранение, най-добре преди датата, идентификационен номер на статия
3. Автоматично създаване на списъци за пазаруване въз основа на минималните нива на запасите и/или най-доброто преди датата
4. Автоматичен отчет за изтекли и изтичащи артикули
5. Лична база данни с възраст, пол, ниво на активност (за изчисляване на нуждите)
6. Изчисляване на нуждите и покритие на наличната храна
7. Преглед на хранителните вещества на съхраняваната храна въз основа на препоръчаното разпределение.

Ако можех да програмирам, сигурно щях да го реша с база данни. За съжаление не мога. Никой не ме е заблудил за това в Excel.

Убийте човек, изкопайте два гроба.

Но за експлоатацията на базата данни не е необходимо пълно копие на базата данни FDDB.
В "мирно време" информацията от FDDB се извиква, когато статията се съхранява и след това се обработва и получената информация се съхранява локално. Това по никакъв начин не е нарушение на правилата за API.
Тази ситуация на комфорт не съществува офлайн и трябва да я въведете ръчно.

Тъй като заглавието Модел на данни казва, че започнах да се занимавам с такъв

продукт
-------
Product_ID INTEGER
Product_NAM VARCHAR (50)
Product_TXT VARCHAR (255)

съставна част
-----------
Component_ID INTEGER
Компонент_NAM VARCHAR (50)
Компонент_TXT VARCHAR (255)

мерна единица
-------
ID_на единица
Unit_NAM VARCHAR (50)
Unit_TXT VARCHAR (255)

Количество съставки
----------------
Product_ID INTEGER
Component_ID INTEGER
Quantity_NUM DECIMAL (8.2)
Идентификационен номер на единица INTEGER

продукт
1 - Гулаш - Големият консервиран гулаш с лека нотка лют лют пипер

съставна част
1 - калоричност
2 - яйчен белтък
3 - въглехидрати
4 - захар
5 - мазнини
6 - наситени мазнини
7 - фибри
8 - натрий
9 - витамин С.
10 - сол

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

Количество съставки
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 неща. но преди да помисля по-нататък: върви ли това в правилната посока?