Raktárkezelés - adatmodell - funkciók - felszerelés; Anyag - Felkészültség; Túlélés

Ez most elfér raktárban vagy informatikában, de először azt gondolja, hogy az informatikai terület jobb.
Ha átnézzük a fórumokat, úgy tűnik, hogy szükség van elektronikus raktárkezelésre, de úgy tűnik, hogy a legtöbb projekt viszonylag gyorsan elalszik. Az OpenSource segítségével továbbra is hozzáférhet az adatokhoz, és egy ideig folytathatja a munkát a régi szoftverrel, a már nem karbantartott ClosedSource vagy olyan alkalmazásokkal, a fáradságosan karbantartott adatbázisok egy bizonyos ponton elvesznek.
Saját célokra egy LAMP alapú megoldáson dolgozom (Linux/Apache/mysql/PHP). De az alapul szolgáló adatbázist úgy szeretném megtervezni, hogy az ne csak a kis és közepes méretű projektemhez illeszkedjen, hanem nagyobb és kisebb projekteket is feltérképezhessen. A cél egy olyan adatbázis-struktúra meghatározása, amelyet sokféle projekt használhat - és amely hordozhatóvá teszi az adatokat. Természetesen az alapfunkciókkal ellátott API is benne van.

Alapvető szempontok az adatbázissal kapcsolatban:
- Több kliens képesség, azaz több különálló raktár egy adatbázisban. Biztonsági szempontból, főleg a témáinkkal, nem a NonPlusUltra-val, mivel legalább az admin mindent lát, de lehetőséget kínál teszttáborok felállítására is az élő működés megzavarása nélkül. Végül asztalonként csak egy mező van
- Az EAN/GTIN stb. Megkülönböztető tulajdonságnak kell lennie minden tárolt helyen. Megfelelő számot lehet létrehozni a saját termékek szabad területeiről (újratöltött, saját főtt stb.).
- Kategóriák (az állami rendszerek alapján)
- A tárolási hierarchiának a tárolási hely-> polc-> szint-> sor-> alrekesz kellő rugalmasságot kell kínálnia minden mérethez. Lehetővé kell tenni több helyfoglalást egy tárolórekeszben (nagyon kevesen fogják ezt olyan pontosan megtenni, hogy termékenként/legelőnyösebb dátumként külön rekeszt rendelnének hozzá). Szélsőségesek számára hozzáadhat egy zászlót, amely ellenőrzi ezt a viselkedést.
- az UTF8-on mindennek elégnek kell lennie
- SET képesség, ha mindig ugyanazokat a csomagokat állítja össze. Például számomra ez egy vákuumcsomagolású csomag, alapvető ételekkel egy hétre/egy fő.

Engedély stb.
- Kód és adatbázis struktúra nyílt licenc alatt, de még nem tudom, hogy a GPL, a BSD vagy bármely más olcsóbb-e.
- Mivel a jól karbantartott és ingyenes EAN adatbázisok meglehetősen hiányosak, mindenképpen kézi munkát kell elvégezni. Az összegyűjtött adatoknak (EAN, név, táplálkozási táblázat, kategória hozzárendelés) szabadon cserélhetőknek kell lenniük, és ha szükséges, mindenki számára elérhetővé válnak összegyűjtött formában.

nyitott minden javaslatra - már írtam valami hasonlót egy nagyon régi szálban - valószínűleg túl öreg.

Először is, hosszú és kitartó életet kívánok a projektjének!

Javaslataimat felosztottam a két összetevőre: "szoftver" és "adatbázis", így könnyen áttekinthető, hogy hol találhatók:

"Áthelyezési funkció" (amikor egy élelmiszert áthelyeznek az X polcról Y-re; pl. Térbeli okokból)
Ha az EAN-t kulcsként használják: EAN-generátor (saját ételeihez; hogy Önnek ne kelljen a megfelelő számokat keresnie a szabadon elérhető medencéből, és elkerülje az ismétléseket
Keresés funkció már regisztrált cikkekhez
Ismétlődő ellenőrzés
Ha már több ügyfél képes, akkor egy (opcionális) engedélyezési koncepcióval is.
RDA számítógép (esetleg több RDA-val, mert minden gazdasági térségnek, részben minden országnak megvannak a maga ajánlásai)
Import és export funkció, ha szükséges, géppel és emberrel is olvasható

Nem használnám az EAN-t kulcsként, legfeljebb egyszerű adatmezőként (és nem is kötelező mezőként). Háttér: Nem mindig vásárolok X élelmiszereket ugyanattól a vállalattól (például azért, mert az Inzersd * rfer ma működik, holnap pedig az F * lix.). Számomra azonban a chili con carne nagyrészt megegyezik a chili con carne-val. Vagy Heinz sült babja, néha chilivel, néha anélkül. Táplálkozási értékbeli különbségek két márka vagy fajta között valószínűleg kisebbek, mint két házilag elkészített tétel között.
Mikro- és makrotápanyagok rögzítésének képessége. (Fehérje-, zsír-, víz-, szénhidrát- és cukortartalom, ásványi anyagok, vitaminok, nyomelemek). És természetesen kcal/kJ.
Tartalmazza a tömegegységek grammjain kívül darabokat, adagokat (különösen a vitaminok szempontjából érdekes) és a litereket is.

LG, sok szerencsét és maradóképességet,

Dolgozz, mintha örökké élnél. Szeress, mintha ma halnál meg.

Az EAN adatbázisokba
Az fddb adatbázis még rendelkezik API-val a külső hozzáféréshez, és ingyenes.
https://fddb.info/api/v18/documentation/

[USER = "2997"] Maresi [/ USER] Sajnos nem csak arról van szó, hogy a készételek tartalma cserélhető lenne a különböző gyártók között.
Az árkülönbségek a víz vagy az "olcsó kalóriák", például az ipari cukor vagy a gabona változó arányából adódnak.
Azok számára, akik készleteiket késztermékekre és "dobozokra" alapozzák, egy kész adatbázisra való hivatkozás aranyat érne.

Az FDDB adatbázist az extenderen keresztül használom az étrend tervezéséhez. Ez remekül működik.

Szerintem az egész rendszernek offline állapotban kell maradnia. Tehát jó lenne, ha a békeidőben "gyűjtött" információkat, legyenek azok az fddb-ből vagy más forrásokból, helyben tárolják.

Néhány évvel ezelőtt bemutattam egy "tartalék adatbázist" itt a fórumban. Nem igazi DB alkalmazás, hanem Excel fájl. A funkcionalitás szempontjából nagyjából ez lenne a minimális követelmény egy új rendszer számára számomra.

1. Cikkadatbázis (cikkazonosító, nevek, árak, beszerzési források, tápérték és tápanyageloszlás, cikkkategória, minimális készletszint)
2. Készletkezelés a tárolás dátumával, a tárolás helyével, a legelőnyösebb dátummal, a cikk azonosítójával
3. Bevásárló listák automatikus létrehozása a minimális készletszint és/vagy MHD alapján
4. Lejárt és lejáró elemek automatikus jelentése
5. Személyes adatbázis életkorával, nemével, aktivitási szintjével (a szükségletek kiszámításához)
6. A rendelkezésre álló élelmiszerek szükségleteinek kiszámítása és lefedettsége
7. A tárolt élelmiszerek tápanyag-áttekintése az ajánlott elosztás alapján.

Ha tudnék programozni, valószínűleg megoldottam volna egy adatbázissal. Sajnos nem tudok. Senki nem tévesztett meg ezért az Excel-ben.

Ölj meg egy embert, áss két sírt.

De az FDDB adatbázis teljes másolatára nincs szükség az adatbázis működtetéséhez.
"Békeidőben" az FDDB-től származó információkat hívják elő, amikor a cikket tárolják, majd feldolgozzák, és a kapott információkat helyben tárolják. Ez semmiképpen sem sérti az API-házirendet.
Ez a kényelmi helyzet nem létezik offline állapotban, és manuálisan kell megadnia.

Mivel az Adatmodell címszó szerint elkezdtem bütykölni egyet

termék
-------
Product_ID INTEGER
Product_NAM VARCHAR (50)
Termék_TXT VARCHAR (255)

összetevő
-----------
Component_ID INTEGER
_NAM VARCHAR alkotóelem (50)
Component_TXT VARCHAR (255)

Mértékegység
-------
Unit_ID
Unit_NAM VARCHAR (50)
Unit_TXT VARCHAR (255)

Összetevő mennyisége
----------------
Product_ID INTEGER
Component_ID INTEGER
Mennyiség: NUM DECIMAL (8.2)
Unit_ID INTEGER

termék
1 - Gulyás - A nagy konzerv gulyás, enyhe chili jegyekkel

összetevő
1 - fűtőérték
2 - tojásfehérje
3 - szénhidrátok
4 - cukor
5 - zsír
6 - telített zsír
7 - rost
8 - nátrium
9 - C-vitamin
10 - só

Mértékegység
1 gramm
2 százalék
3 - kcal

Összetevő mennyisége
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

Ami természetesen még hiányzik:
* Csomagolás/tartály (doboz, palack, üveg, papír, stb.)
* Gyártó - esetleg a termék része lehet
* Vásárlás (üzlet, dátum, ár, szám, kedvezmény,.)
* Tárolási hely - szabadon definiált hierarchia. Apartman - szoba - polc - padló - doboz - .
* Kategória (konzervek, köret,.)
* Állapot (konzervek, MRE, nyers, főtt,.)
* Receptek

Nyisd ki
Minőségét megőrzi. Ha ugyanabból a termékből 5 dobozot vásárolok ugyanabban a boltban, akkor is kaphatok 5 legelőnyösebb dátumot

Még 100 dologra tudok gondolni. de mielőtt tovább gondolkodnék: ez jó irányba halad?