problema database prezzi menu

[kekko12]

Salve, sto creando un DB Mysql nel quale verranno inseriti tutti i dati relativi alle comande (ordinazioni) prese in un ristorante (n° coperti, cibo ordinato, cameriere che ha servito, data, ecc).

Il problema che mi sto ponendo da qualche tempo è quello relativo al prezzo degli alimenti ordinati dai clienti.

Infatti sono ben conscio del fatto che andrà creata una tabella "menu" con dentro i campi nome e prezzo per ogni alimento ordinabile nel menù. Il problema che sorge è: ma quando i prezzi del menù cambieranno, come fare in modo che i prezzi relativi alle ordinazioni effettuate in data precedente al cambio di prezzo non cambino anche a loro volta?

Perchè in quel caso avrei le ordinazioni vecchie con i prezzi nuovi, e questo non andrebbe bene (soprattutto considerando che ha molta rilevanza il totale speso per ciascun tavolo).

Ho pensato a creare due prezzi, uno "storico" e uno "attuale" ma non saprei in che modo servirmene per la mia causa.

Spero che almeno stavolta qualcuno mi aiuti. Grazie.

[daniele_dll]

molto semplicemente, la tabella delle ordinazioni deve contenere tutti gli elementi necessari per il calcolo

inoltre devi far si che i record dalla tabella menù non vengano "fisicamente" cancellati, per farli sparire devi gestire un flag a livello logico (una enum si/no, un tinyint 0/1 o cose così) così da nascondere i record "pseudo-eliminati"

questo ti serve in quanto se cancelli un record dal menù perdi il riferimento quando leggi i dati dalla tabella delle ordinazioni

tra l'altro questo ti permette anche di fare elaborazioni statistiche sui dati pregressi con una certa tranquillità visto che lo storico del menù sarà sempre presente

[kekko12]

Grazie davvero! In effetti non avevo pensato alle complicazioni derivanti l'eliminazione di voci dal menù. Inserirò un campo nella tabella "menu" chiamandolo "in_uso" che sarà si/no e che solo quando sarà "si" mostrerà i record del menu all'utente.

Invece rimane il dubbio per quanto riguarda i prezzi. Purtroppo non ho capito cosa tu intenda dicendo che nella tabella delle ordinazioni devo inserire tutti gli elementi necessari per il calcolo. Puoi darmi altre delucidazioni????


Grazie!!!

p.s.
perchè per tenere lo storico del menu mi suggerisci di inserire un campo di tipo tinyint o enum invece che un boolean?

[daniele_dll]

ehm ... su mysql mica esiste il boolean (o per lo meno fino alla 5.5.12 non esiste) e per avere un campo con 2 o più stati in modo efficiente solitamente si usa un ENUM (mysql assegna ad ogni stringa un valore e poi usa quello nell'archivio dati così lo si vede come stringa ma internamente è un valore numeri che è più rapido da confrontare/ricercare e soprattutto consuma meno spazio)

un flag "in_uso" non risolve il problema

La logica deve essere che i record non devono MAI essere eliminati tramite DELETE, piuttosto fai una query di UPDATE impostando un flat eliminato su Si (o su 0 se fai un tinyint), flag che usi per filtrare i risultati che estrai quando mostri il menù a video (mostri solo i record che hanno il flag a no filtrando tramite il WHERE).
Con questo banale sistema tu esegui un'eliminazione del dato non a livello fisico, ma a livello logico.

Nel contempo, questo ti permette di mostrare SEMPRE il nome/descrizione associato.

Addirittura ti direi, per risolvere proprio il problema alla base, di usare una logica di "revisioni", ogni modifica non aggiorna il record del menù bensì ne inserisce uno nuovo ad hoc.
I record "precedenti" avranno un flag "storico" (enum si/no oppure tinyint 1/0) messo su si per indicare che sono storici e non ti interessano mentre il record nuovo non avrà un flag storico.
Con una logica di questo tipo non devi preoccuparti più di nulla, l'ordinazione sarà legato a quel specifico menù che c'era in quel dato periodo.

Ti dico questo perché oltre al prezzo potrebbero variare gli ingredienti, il nome ed altro e quindi faresti vedere, nello storico delle ordinazioni, cose errate.

Quindi puoi fare una tabella menù, ad esempio, così:
- menu_id - INT(10) UNSIGNED PRIMARY KEY AUTOINCREMENT
- menu_storico - ENUM('Si','No')
- menu_titolo - VARCHAR(255)
- menu_descrizione - TEXT
- menu_prezzo - DECIMAL(10,2) UNSIGNED
- menu_eliminato - ENUM('Si','No')

Quando viene fatta una modifica effettui una UPDATE per impostare nel record corrente il flag menu_storico su Si e poi viene effettuato un nuovo inserimento con il flag menu_storico su No.

La tabella delle ordinazioni, invece, la fai così:
- ordinazione_id - INT(10) UNSIGNED PRIMARY KEY AUTOINCREMENT
- ordinazione_menu_id - INT(10) UNSIGNED INDEX (magari fai una foreign key verso menu_id)
- ordinazione_quantita - TINYINT(255)
- ordinazione_prezzo_totale - DECIMAL(10,2)
- ordinazione_data - DATETIME

Lo so che può sembrare una logica "complessa" però questo meccanismo ti permette, con semplicità perché di complesso non c'è nulla, di gestire tutto perfettamente e di dare sempre i dati corretti a video!

[philbert]

Originariamente inviato da kekko12
Invece rimane il dubbio per quanto riguarda i prezzi. Purtroppo non ho capito cosa tu intenda dicendo che nella tabella delle ordinazioni devo inserire tutti gli elementi necessari per il calcolo. Puoi darmi altre delucidazioni????

Ciao,
in pratica nella tabella delle ordinazioni cideve essere anche il campo prezzo , che tu puoi anche andare a leggere di volta in volta dalla tabella menu, ma una volta inserito rimarrà poi quello

[daniele_dll]

Originariamente inviato da philbert
Ciao,
in pratica nella tabella delle ordinazioni cideve essere anche il campo prezzo , che tu puoi anche andare a leggere di volta in volta dalla tabella menu, ma una volta inserito rimarrà poi quello

il campo prezzo non è l'unica cosa che può variare, se cambia leggermente la descrizione o leggermente gli ingredienti perché a chi usa il software gli stuffa fare da zero la scheda del prodotto che si fa?

un meccanismo basato sulle revisioni, che è veramente semplice da fare, risolve il problema in maniera efficiente sia dal punto di vista funzionale sia da quello dello storage:
- i dati sono storicizzati e l'ordinazione è legata a quel dato menù
- invece di riportare, oltre al prezzo, anche le informazioni generali relative al menù nella tabella delle ordinazioni, si ci mette solo l'id

Se poi vuoi dare la possibilità al gestore di applicare "correzioni", ovvero ha scritto sbagliato qualcosa, puoi mettere una spunta, magari chiamandola correzione minore o qualcosa del genere, che nel caso sia flaggata fa un normale update dei valori (ovviamente dovresti controllare che il prezzo rimanga uguale per essere sicuri che non facciano robe strane )

[gabama_com]

Per non complicarti la vita, la cosa più semplice ed efficace è quella di "copiare" i valori che non dovranno essere aggiornati in caso di modifica futura (descrizione, prezzo ecc.) direttamente sul record dell'ordinazione.

[daniele_dll]

effettuare un inserimento ex novo ogni volta e flaggare il precedente come vecchio è complicarsi la vita? al massimo è fare le cose per bene evitando dati ridondanti e mantenendo la possibilità di riutilizzare la stessa logica per gestire quasi interamente il lato ordinazioni (quindi si evita inutile duplicazione di codice)

[gabama_com]

Sicuramente il tuo metodo è quello formalmente più corretto.

[nman]

Mi piace l'idea di daniele !