Skladové hospodárstvo - dátový model - funkcie - vybavenie; Materiál - pripravenosť; Prežitie

To by sa teraz mohlo hodiť na sklad alebo do IT, ale najskôr si myslite, že oblasť IT je lepšia.
Ak sa pozriete cez fóra, zdá sa, že je potrebná elektronická správa skladov, ale zdá sa, že väčšina projektov zaspáva pomerne rýchlo. S OpenSource sa stále môžete dostať k dátam a istý čas môžete pokračovať v práci so starým softvérom, s ClosedSource alebo aplikáciami, ktoré už nie sú udržiavané, sa pracne udržiavané databázy v určitom okamihu stratia.
Pre svoje vlastné účely pracujem na riešení založenom na LAMPE (Linux/Apache/mysql/PHP). Ale chcel by som navrhnúť podkladovú databázu tak, aby vyhovovala nielen môjmu malému a strednému projektu, ale mohla mapovať aj väčšie a menšie projekty. Cieľom je definovať databázovú štruktúru, ktorú môžu používať najrôznejšie projekty - a ktorá umožňuje prenosnosť údajov. Súčasťou je samozrejme aj API so základnými funkciami.

hospodárstvo

Základné informácie o databáze:
- Možnosť viacerých klientov, t. J. Niekoľko samostatných skladov v jednej databáze. Z bezpečnostného hľadiska, najmä pokiaľ ide o naše témy, nie o NonPlusUltra, pretože prinajmenšom administrátor vidí všetko, ale ponúka aj možnosť usporiadania testovacích táborov bez narušenia živej prevádzky. Nakoniec je to iba jedno ďalšie pole na stôl
- EAN/GTIN atď. By mal byť charakteristickým znakom všetkého uloženého. Z voľných plôch je možné vygenerovať zodpovedajúce číslo pre vaše vlastné výrobky (znovu naplnené, samovarené atď.).
- Kategórie (na základe štátnych systémov)
- Hierarchia úložiska z umiestnenia úložiska-> police-> úroveň-> riadok-> podpriehradka by mala ponúkať dostatočnú flexibilitu pre všetky veľkosti. Malo by byť možné vykonať viac rezervácií v úložnom priestore (len veľmi málo z nich to urobí tak presne, že je pre každý produkt/dátum minimálnej trvanlivosti priradená samostatná priehradka). Pre extrémistov môžete pridať príznak, ktorý riadi toto správanie.
- všetko na UTF8 by malo stačiť
- Možnosť SET, ak dávate dokopy rovnaké balíčky. Napríklad pre mňa by to boli vákuovo balené balenia so základným jedlom na týždeň/jedna osoba.

Licencia atď.
- Štruktúra kódu a databázy pod otvorenou licenciou, ale zatiaľ neviem, či je GPL, BSD alebo akákoľvek iná lacnejšia.
- Pretože dobre udržiavaných a bezplatných databáz EAN je skôr nedostatok, určite je treba urobiť niekoľko manuálnych prác. Zhromaždené údaje (EAN, meno, nutričná tabuľka, priradenie kategórií) by mali byť voľne zameniteľné a v prípade potreby by mali byť dostupné všetkým v zhromaždenej podobe.

otvorené všetkým návrhom - niečo podobné som už napísal vo veľmi starom vlákne - pravdepodobne príliš starom.

V prvom rade prajem vášmu projektu dlhý a plnohodnotný život!

Moje návrhy som rozdelil na dve zložky „softvér“ a „databáza“, aby bolo ľahké zistiť, kde ich nachádzam:

  • „Funkcia premiestnenia“ (keď je potravina premiestnená z police X do Y; napr. Z priestorových dôvodov)
  • Ak sa ako kľúč použije EAN: Generátor EAN (pre vaše vlastné potraviny; aby ste nemuseli hľadať správne čísla z voľne dostupného fondu a aby ste sa vyhli duplikátom.
  • Funkcia vyhľadávania už registrovaných článkov
  • Duplicitná kontrola
  • Ak už je schopný pracovať s viacerými klientmi, potom aj s (voliteľným) konceptom autorizácie.
  • Počítač RDA (možno s niekoľkými RDA, pretože každá ekonomická oblasť, čiastočne každá krajina, má svoje vlastné odporúčania)
  • Funkcia importu a exportu, v prípade potreby alternatívne strojovo a ľudsky čitateľná

  • Nepoužíval by som EAN ako kľúč, nanajvýš ako jednoduché dátové pole (a už vôbec nie ako povinné pole). Pozadie: Nie vždy kupujem potraviny X od tej istej spoločnosti (napr. Pretože Inzersd * rfer je dnes v akcii a F * lix zajtra.). Pre mňa je však chili con carne do veľkej miery to isté ako chili con carne. Alebo Heinzove pečené fazule, niekedy s chilli, niekedy bez. Rozdiely v nutričnej hodnote medzi dvoma značkami alebo odrodami budú pravdepodobne menšie ako medzi dvoma domácimi šaržami.
  • Schopnosť zaznamenávať mikroživiny a makroživiny. (Obsah bielkovín, tukov, vody, uhľohydrátov a cukrov, minerály, vitamíny, stopové prvky). A samozrejme kcal/kJ.
  • Okrem gramov ako jednotka hmotnosti zahrňte aj kúsky, porcie (obzvlášť zaujímavé pre vitamíny) a litre.

LG, veľa šťastia a stále sily,

Pracujte, akoby ste žili večne. Milujte, akoby ste dnes zomreli.

Do databáz EAN
Databáza fddb má dokonca API pre externý prístup a je zadarmo.
https://fddb.info/api/v18/documentation/

[USER = "2997"] Maresi [/ USER] Bohužiaľ to tak nie je, keď je obsah hotových jedál zameniteľný medzi rôznymi výrobcami.
Cenové rozdiely sú výsledkom rôzneho podielu vody alebo „lacných kalórií“, ako je priemyselný cukor alebo obilie.
Pre tých, ktorí zakladajú svoje zásoby na hotových výrobkoch a „plechovkách“, by odkaz na hotovú databázu stál za zlato.

Na plánovanie diéty používam databázu FDDB cez extender. To funguje výborne.

Myslím si, že celý systém MUSÍ zostať offline. Bolo by teda dobré, keby sa informácie „zhromažďované“ počas mieru, či už z fddb alebo iných zdrojov, ukladali lokálne.

Pred niekoľkými rokmi som tu na fóre predstavil „rezervnú databázu“. Nie však skutočná aplikácia DB, ale súbor programu Excel. Z hľadiska funkčnosti by to pre mňa bolo zhruba minimálna požiadavka na nový systém.

1. Databáza článkov (ID článku, názvy, ceny, zdroje dodávok, výživová hodnota a distribúcia živín, kategória článku, minimálna úroveň zásob)
2. Správa zásob s dátumom úložiska, umiestnením úložiska, dobou spotreby, ID článku
3. Automatické vytváranie nákupných zoznamov na základe minimálnych úrovní zásob a/alebo MHD
4. Automatická správa o expirovaných a expirujúcich položkách
5. Osobná databáza s vekom, pohlavím, úrovňou aktivity (pre výpočet potrieb)
6. Výpočet potrieb a pokrytia dostupnej stravy
7. Prehľad živín skladovaných potravín na základe odporúčaného rozdelenia.

Keby som vedel programovať, asi by som to vyriešil pomocou databázy. Bohužiaľ nemôžem. V Exceli ma za to nikto neklamal.

Zabite človeka, vykopajte dva hroby.

Na fungovanie databázy však nie je potrebná úplná kópia databázy FDDB.
V „mierovom období“ sa informácie z FDDB vyvolajú, keď sa výrobok uloží, potom sa spracuje a získané informácie sa uložia lokálne. To v žiadnom prípade nie je porušením pravidiel API.
Táto komfortná situácia neexistuje offline a musíte ju zadať manuálne.

Pretože nadpis Dátový model hovorí, že som si začal niečo pohrávať

výrobok
-------
ID_produktu INTEGER
Product_NAM VARCHAR (50)
Produkt_TXT VARCHAR (255)

zložka
-----------
Zložka_ID INTEGER
Component_NAM VARCHAR (50)
Komponent_TXT VARCHAR (255)

jednotka
-------
Unit_ID
Unit_NAM VARCHAR (50)
Jednotka_TXT VARCHAR (255)

Množstvo prísady
----------------
ID_produktu INTEGER
Zložka_ID INTEGER
Quantity_NUM DECIMAL (8,2)
Unit_ID INTEGER

výrobok
1 - Guláš - Skvelý konzervovaný guláš s jemnou chilli poznámkou

zložka
1 - výhrevnosť
2 - vaječný bielok
3 - sacharidy
4 - cukor
5 - tučný
6 - nasýtené tuky
7 - vlákno
8 - sodík
9 - vitamín C.
10 - soľ

jednotka
1 gram
2 percentá
3 - kcal

Množstvo prísady
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

Čo samozrejme ešte chýba:
* Balenie/nádoba (plechovka, fľaša, sklo, papier,.)
* Výrobca - môže byť súčasťou produktu
* Nákup (dohoda, dátum, cena, číslo, zľava,.)
* Umiestnenie úložiska - voľne definovaná hierarchia. Apartmán - izba - polica - podlaha - krabica - .
* Kategória (konzervy, prílohy,.)
* Stav (konzervy, MRE, surové, varené,.)
* Recepty

Otvorené
Najlepšie pred. Ak v tom istom obchode kúpim 5 plechoviek toho istého produktu, stále môžem mať 5 dátumov spotreby

Napadá mi ďalších 100 vecí. ale skôr, ako si pomyslím ďalej: ide to správnym smerom?