Designing Consistent Module di fatturazione

Come regola generale, i prodotti non hanno prezzi, proprio per la ragione per cui vi siete imbattuti: i prezzi possono cambiare.

Al contrario. una tabella "prodotto" verrà unita a una tabella "offerta" che contiene il prezzo e una data di inizio e fine, nonché altre potenziali regole (ad esempio condizioni di vendita speciali o preferenza del fornitore).

Puoi vedere questa struttura, ad esempio, nel database Magento schema . Magento è una piattaforma di e-commerce molto popolare che memorizza i prezzi dei prodotti in una tabella denominata catalogrule_product_price . Noterai che la tabella catalog_product_entity non contiene alcun prezzo.

Gli elementi pubblicitari della fattura si collegherebbero a un'offerta. Il prezzo di un'offerta non può mai cambiare. Per modificare il prezzo di un prodotto, devi aggiungere una nuova offerta al prodotto e scadere quella precedente. I collegamenti all'offerta originale rimarrebbero validi, pertanto gli elementi pubblicitari della fattura rimarranno intatti e precisi.

Se è necessario essere in grado di ricreare una fattura con i contenuti originali esatti in qualsiasi momento in futuro, indipendentemente da ciò che accade con i contenuti del proprio database, allora ci sono essenzialmente due approcci che è possibile adottare.

1. Progetta il tuo database come "aggiungi solo": i record esistenti non vengono mai modificati. Se è necessario modificare, ad esempio, il prezzo di un prodotto, allora non si aggiorna il record della tabella per quel prodotto, ma piuttosto si aggiunge un nuovo record per il prodotto con il nuovo prezzo.
   Se disponi di molte tabelle con collegamenti tra loro, questo schema causerà molte modifiche a cascata e dovrai riflettere attentamente su come recuperare solo la versione più recente di qualsiasi oggetto quando esegui una query generale.

2. Si duplicano le informazioni pertinenti sul prodotto nelle righe InvoiceItem. Avere bisogno di accedere ai valori dei dati così come erano in un determinato momento può essere un valido motivo per de-normalizzare il database.

La linea di fondo è che è necessario assicurarsi che eventuali aggiornamenti al database non distruggano i vecchi dati che potrebbero essere necessari per la generazione della fattura.