Gestionarea depozitelor - model de date - funcții - echipamente; Material - Pregătire; Supravieţuire

Asta s-ar putea potrivi acum în stoc sau IT, dar mai întâi credeți că zona IT este mai bună.
Dacă te uiți prin forumuri, pare să fie nevoie de gestionarea electronică a depozitelor, dar majoritatea proiectelor par să adoarmă relativ repede. Cu OpenSource puteți accesa în continuare datele și puteți continua să lucrați cu software-ul vechi pentru o perioadă de timp, cu ClosedSource sau aplicații care nu mai sunt întreținute, bazele de date menținute laborios se pierd la un moment dat.
În scopuri proprii, lucrez la o soluție bazată pe LAMP (Linux/Apache/mysql/PHP). Dar aș dori să proiectez baza de date de bază în așa fel încât să nu se potrivească doar proiectului meu de dimensiuni mici și mijlocii, dar să poată mapa și proiecte din ce în ce mai mari. Scopul este de a defini o structură de baze de date care poate fi utilizată de o mare varietate de proiecte - și care face ca datele să fie portabile. Desigur, este inclus și un API cu funcțiile de bază.

Considerații de bază despre baza de date:
- Capacitate multi-client, adică mai multe depozite separate pe o bază de date. Din punct de vedere al securității, mai ales cu subiectele noastre, nu cu NonPlusUltra, deoarece cel puțin administratorul vede totul, dar oferă și posibilitatea de a înființa tabere de testare fără a deranja operațiunea live. În cele din urmă, este doar un câmp pe tabel
- EAN/GTIN etc. ar trebui să fie o caracteristică distinctivă pentru tot ceea ce este stocat. Un număr corespunzător poate fi generat din zonele libere pentru propriile produse (reumplute, auto-fierte etc.).
- Categorii (bazate pe sistemele de stat)
- Ierarhia de stocare de la locația de stocare-> raft-> nivel-> rând-> sub-compartiment ar trebui să ofere suficientă flexibilitate pentru toate dimensiunile. Rezervări multiple pe un compartiment de depozitare ar trebui să fie posibile (foarte puțini vor face acest lucru atât de precis încât să fie atribuit un compartiment separat pentru fiecare produs/MHD.). Pentru extremiști, puteți adăuga un semnal care controlează acest comportament.
- totul de pe UTF8 ar trebui să fie suficient
- Abilitatea SET dacă întotdeauna puneți împreună aceleași pachete. Pentru mine, de exemplu, ar fi pachete ambalate sub vid cu alimente de bază pentru o săptămână/o persoană.

Licență etc.
- Structura codului și a bazei de date sub licență deschisă, dar nu știu încă dacă GPL, BSD sau orice altul este mai ieftin.
- Deoarece bazele de date EAN bine întreținute și gratuite sunt destul de puține, există cu siguranță o lucrare manuală de făcut. Datele colectate (EAN, nume, tabel nutrițional, atribuirea categoriilor) ar trebui să fie liber schimbabile și, dacă se dorește, să fie disponibile tuturor într-o formă colectată.

deschis tuturor sugestiilor - am scris deja ceva similar într-un fir foarte vechi - probabil prea vechi.

În primul rând, îți doresc proiectului tău o viață lungă și împlinită!

Am împărțit sugestiile mele în cele două componente „software” și „bază de date”, astfel încât să fie ușor de văzut unde le localizez:

„Funcția de relocare” (atunci când un produs alimentar este mutat din spațiul de raft X în Y; de exemplu, din motive de spațiu)
Dacă EAN este folosit ca cheie: generatorul EAN (pentru propria hrană; astfel încât să nu trebuie să căutați singur numerele corecte din piscina disponibilă gratuit și să evitați duplicatele
Funcția de căutare a articolelor deja înregistrate
Verificare duplicat
Dacă este deja compatibil cu mai mulți clienți, atunci și cu un concept de autorizare (opțional).
Computer ADR (posibil cu mai multe ADR, deoarece fiecare zonă economică, parțial fiecare țară, are propriile recomandări)
Funcția de import și export, dacă este necesar, alternativ lizibilă de mașină și citită de om

Nu aș folosi EAN ca cheie, cel mult ca un simplu câmp de date (și nici măcar ca un câmp obligatoriu). Context: Nu cumpăr întotdeauna alimente X de la aceeași companie (de exemplu, deoarece Inzersd * rfer este în acțiune astăzi și F * lix mâine.). Cu toate acestea, pentru mine, chili con carne este în mare parte același cu chili con carne. Sau fasolea lui Heinz, uneori cu chilli, alteori fără. Diferențele de valoare nutrițională între două mărci sau soiuri sunt probabil mai mici decât între două loturi gătite acasă.
Capacitatea de a înregistra micro și macronutrienți. (Conținut de proteine, grăsimi, apă, carbohidrați și zahăr, minerale, vitamine, oligoelemente). Și desigur kcal/kJ.
În plus față de grame ca unitate de greutate, includeți și bucăți, porții (deosebit de interesante pentru vitamine) și litri.

LG, noroc și putere de ședere,

Lucrează ca și cum ai trăi veșnic. Iubește de parcă ai muri azi.

La bazele de date EAN
Baza de date fddb are chiar și un API pentru acces extern și este gratuită.
https://fddb.info/api/v18/documentation/

[USER = "2997"] Maresi [/ USER] Din păcate, nu este cazul ca conținutul meselor gata să fie interschimbabil între diferiții producători.
Diferențele de preț rezultă din proporția variabilă de apă sau „calorii ieftine”, cum ar fi zahărul industrial sau cerealele.
Pentru cei care își bazează stocurile pe produse finite și „conserve”, o referință la o bază de date finită ar merita aurul.

Folosesc baza de date FDDB prin extender pentru planificarea dietei. Asta funcționează excelent.

Cred că întregul sistem TREBUIE să rămână offline. Deci, ar fi bine dacă informațiile „colectate” în timpul păcii, fie din fddb sau din alte surse, sunt stocate local.

Acum câțiva ani am prezentat o „bază de date de rezervă” aici, pe forum. Nu o aplicație DB reală, ci un fișier Excel. În ceea ce privește funcționalitatea, aceasta ar fi aproximativ cerința minimă pentru un nou sistem pentru mine.

1. Baza de date a articolelor (codul articolului, nume, prețuri, surse de aprovizionare, valoare nutrițională și distribuția nutrienților, categoria articolelor, nivelul minim al stocului)
2. Gestionarea inventarului cu data de stocare, locația de stocare, data cea mai bună înainte, ID-ul articolului
3. Crearea automată a listelor de cumpărături pe baza nivelurilor minime de stoc și/sau MHD
4. Raport automat al articolelor expirate și expirate
5. Baza de date personală cu vârsta, sexul, nivelul de activitate (pentru calculul nevoilor)
6. Calcularea nevoilor și acoperirea alimentelor disponibile
7. Prezentare generală a nutrienților alimentelor depozitate pe baza distribuției recomandate.

Dacă aș putea programa, probabil aș fi rezolvat-o cu o bază de date. Din păcate nu pot. Nimeni nu m-a păcălit pentru asta în Excel.

Omoară un om, sapă două morminte.

Dar o copie completă a bazei de date FDDB nu este necesară pentru a opera baza de date.
În „timp de pace”, informațiile din FDDB sunt apelate atunci când articolul este stocat și apoi procesat, iar informațiile obținute sunt stocate local. Aceasta nu este în niciun caz o încălcare a politicii API.
Această situație de confort nu există offline și trebuie să o introduceți manual.

Întrucât titlul Model de date spune că am început să-l joc

produs
-------
Product_ID INTEGER
Product_NAM VARCHAR (50)
Product_TXT VARCHAR (255)

componentă
-----------
Component_ID INTEGER
Component_NAM VARCHAR (50)
Component_TXT VARCHAR (255)

unitate
-------
ID_unitate
Unit_NAM VARCHAR (50)
Unit_TXT VARCHAR (255)

Cantitate de ingrediente
----------------
Product_ID INTEGER
Component_ID INTEGER
Cantitate_NUM DECIMAL (8.2)
Unit_ID INTEGER

produs
1 - Gulaș - Marele gulaș conservat, cu o ușoară notă de ardei iute

componentă
1 - puterea calorică
2 - albus de ou
3 - carbohidrați
4 - zahăr
5 - grăsime
6 - grăsimi saturate
7 - fibră
8 - sodiu
9 - vitamina C.
10 - sare

unitate
1 gram
2 la sută
3 - kcal

Cantitate de ingrediente
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

Ce lipsește, desigur:
* Ambalaj/recipient (cutie, sticlă, sticlă, hârtie etc.)
* Producător - ar putea face parte din produs
* Achiziție (ofertă, dată, preț, număr, reducere.)
* Locație de stocare - ierarhie definită liber. Apartament - cameră - raft - podea - cutie - .
* Categorie (conserve, garnitură.)
* Stare (conserve, MRE, crud, gătit.)
* Rețete

Deschis
Data expirării. Dacă cumpăr 5 cutii cu același produs în același magazin, totuși pot avea 5 date de expirare

Mă pot gândi la încă 100 de lucruri. dar înainte să mă gândesc mai departe: merge acest lucru în direcția corectă?