Progettazione del database di inventario [chiuso]

https://stackoverflow.com/questions/287097

08-07-2019
|

Domanda

Questa è una domanda che non riguarda veramente " programmazione " (non è specifico per nessuna lingua o database), ma più di design e architettura. È anche una domanda del tipo "qual è il modo migliore per fare X". Spero che non causi molto "religioso" polemiche.

In passato ho sviluppato sistemi che in un modo o nell'altro mantengono una forma di inventario degli articoli (non rilevante quali articoli). Alcuni utilizzano linguaggi / DB che non supportano le transazioni. In quei casi ho scelto di non salvare l'articolo quantità disponibile in un campo nel record dell'articolo. Invece la quantità disponibile viene calcolata per il totale delle scorte ricevute - totale delle scorte vendute. Ciò ha comportato pressoché nessuna discrepanza nell'inventario a causa del software. Le tabelle sono correttamente indicizzate e le prestazioni sono buone. Esiste un processo di archiviazione nel caso in cui la quantità di record inizi a influire sulle prestazioni.

Ora, alcuni anni fa ho iniziato a lavorare in questa azienda e ho ereditato un sistema che tiene traccia dell'inventario. Ma la quantità viene salvata in un campo. Quando viene registrata una voce, la quantità ricevuta viene aggiunta al campo quantità per l'articolo. Quando un articolo viene venduto, la quantità viene sottratta. Ciò ha comportato discrepanze. Secondo me questo non è l'approccio giusto, ma i programmatori precedenti qui lo giurano.

Vorrei sapere se esiste un consenso su quale sia il modo giusto di progettare tale sistema. Inoltre, quali risorse sono disponibili, stampate o online, per chiedere assistenza in merito.

Grazie

Soluzione

Ho visto entrambi gli approcci nella mia attuale azienda e mi sarei decisamente orientato verso il primo (calcolando i totali in base alle transazioni azionarie).

Se stai memorizzando una quantità totale in un campo da qualche parte, non hai idea di come sei arrivato a quel numero. Non esiste una cronologia delle transazioni e si possono riscontrare problemi.

L'ultimo sistema che ho scritto tiene traccia delle scorte memorizzando ogni transazione come un record con una quantità positiva o negativa. Ho scoperto che funziona molto bene.

Altri suggerimenti

Ho Vol 1 e Vol 2 e questi sono stati molto utili in passato.

Dipende, i sistemi di inventario vanno ben oltre il semplice conteggio degli articoli. Ad esempio, a fini contabili, potrebbe essere necessario conoscere il valore contabile dell'inventario in base al modello FIFO (First-in-First-out). Questo non può essere calcolato dal semplice "totale dell'inventario ricevuto - totale dell'inventario venduto" formula. Ma il loro modello potrebbe calcolarlo facilmente, perché modificano il valore contabile mentre procedono. Non voglio entrare nei dettagli perché questo non è un problema di programmazione, ma se lo giurano, forse non hai compreso appieno tutti i loro requisiti che devono soddisfare.

entrambi sono validi, a seconda delle circostanze. Il primo è il migliore quando valgono le seguenti condizioni:

il numero di elementi da sommare è relativamente piccolo
ci sono pochi o nessun caso eccezionale da considerare (resi, aggiustamenti, ecc.)
la quantità dell'articolo di magazzino non è necessaria molto spesso

d'altro canto, se si dispone di un numero elevato di articoli, di numerosi casi eccezionali e di un accesso frequente, sarà più efficiente mantenere la quantità degli articoli

nota anche che se il tuo sistema presenta discrepanze, allora ha dei bug che dovrebbero essere rintracciati ed eliminati

Ho fatto i sistemi in entrambi i modi, ed entrambi i modi possono funzionare bene - purché tu non ignori i bug!

Dai un'occhiata al modello di dati ARTS (Association for Retail Technology Standards) ( http://nrf-arts.org ). Utilizza una tabella StockLedger con un record per ogni articolo e le modifiche all'inventario sono tutte tracciate in InventoryJournalEntries.

È importante considerare il sistema esistente e il costo e il rischio di cambiarlo. Lavoro con un database che memorizza l'inventario come il tuo, ma include cicli di audit e memorizza le rettifiche proprio come le ricevute. Sembra funzionare bene, ma tutti i soggetti coinvolti sono ben addestrati e il personale del magazzino non è esattamente pronto ad apprendere nuove procedure.

Nel tuo caso, se stai cercando un po 'più di monitoraggio senza cambiare l'intera struttura del database, ti suggerirei di aggiungere una tabella di monitoraggio (un po' come dalla tua soluzione 'transazione') e quindi registrare le modifiche all'inventario livello. Non dovrebbe essere troppo difficile aggiornare la maggior parte delle modifiche al livello di inventario in modo da lasciare un registro delle transazioni. È inoltre possibile aggiungere un'attività periodica per eseguire il backup del livello di inventario nella tabella delle transazioni ogni due ore circa in modo tale che anche se si perde una transazione, è possibile scoprire quando è avvenuta la modifica o tornare a uno stato precedente.

Se vuoi vedere come un'applicazione di grandi dimensioni dà un'occhiata a SugarCRM , hanno e inventario modulo di gestione anche se non sono sicuro di come memorizza i dati.

Penso che questa sia in realtà una domanda generale sulle migliori pratiche per fare un conteggio (relativamente) costoso ogni volta che hai bisogno di un conteggio totale rispetto a fare ogni volta che qualcosa cambia, quindi archiviare il conteggio in un campo e leggere quel campo ogni volta hai bisogno di un totale.

Se non potessi usare le transazioni, andrei con il conteggio live ogni volta che ho bisogno di un totale. Se le transazioni sono disponibili, sarebbe sicuro eseguire le operazioni di aggiornamento dell'inventario e il salvataggio del totale contato all'interno della stessa transazione, il che garantirebbe l'accuratezza del conteggio (anche se non sono sicuro che funzionerebbe con più utenti colpire il database).

Ma se le prestazioni non sono davvero un grosso problema (e i database moderni sono abbastanza buoni nel contare le righe che raramente mi preoccuperei di questo) mi limiterei a tenere il conto dal vivo ogni volta.

Opterei per il primo modo, dove

viene calcolata la quantità disponibile inventario totale ricevuto - totale di inventario venduto

La strada giusta, IMO.

MODIFICA: Vorrei anche tenere conto di eventuali perdite / danni alle scorte nel sistema, ma sono sicuro che hai coperto.

Ho già lavorato su sistemi che risolvono questo problema. Penso che la soluzione ideale sia una colonna pre-calcolata, che ti offre il meglio di entrambi i mondi. Il tuo totale sarebbe un campo da qualche parte, quindi nessuna ricerca costosa, ma non può non essere sincronizzato con il resto dei tuoi dati (il database mantiene l'integrità). Non ricordo quali RDMS supportano colonne pre-calcolate, ma se non si dispone di transazioni, potrebbe non essere disponibile neanche.

Potresti potenzialmente falsificare colonne pre-calcolate (in modo molto efficace ... non vedo alcun lato negativo) usando i trigger. Probabilmente avresti bisogno di transazioni però. IMHO, mantenere l'integrità dei dati quando si esegue questo tipo di denormalizzazione controllata è l'unico uso legittimo per un trigger.

inventario di Django orientato maggiormente alle immobilizzazioni, ma potrebbe darti idee.

IE: ItemTemplate (class) - > ItemsOnHand (istanza)

ItemsOnHand può essere collegato a più ItemTemplates; Esempio Stampante e amp; è richiesta la cartuccia d'inchiostro. Ciò consente anche di impostare i punti di riordino per ogni ItemOnHand.

Ogni ItemsOnHand è collegato a InventoryTransactions, questo consente un facile controllo. Per evitare il calcolo di articoli a portata di mano effettivi da migliaia di transazioni invasive, vengono utilizzati punti di controllo che sono solo un saldo + una data. Per calcolare gli articoli disponibili, cercare il punto di controllo più recente e iniziare ad aggiungere o sottrarre gli articoli per trovare il saldo attuale degli articoli. Definire periodicamente nuovi checkpoint.

Riesco a vedere alcuni vantaggi nell'avere le due colonne, ma non sto seguendo la parte relativa alle discrepanze: sembra che tu abbia implicato che avere le due colonne (dentro e fuori) sia meno soggetto a discrepanza rispetto a una singola colonna ( attuale). Perché?

Non ho una o due colonne, cosa intendevo con "inventario totale ricevuto - totale di inventario venduto" è qualcosa del genere:

Select sum(quantity) as inventory_received from Inventory_entry
Select sum(quantity) as inventory_sold from Sales_items

quindi

Qunatity_on_hand = inventory_received - inventory_sold

Tieni presente che ho semplificato troppo questa e la mia spiegazione iniziale. So che c'è molto di più nell'inventario che tiene semplicemente traccia delle quantità, ma in questo caso sono state le bugie e ciò che vogliamo risolvere. A questo punto la ragione per cambiarlo è precisamente il costo di supportare i problemi causati dal progetto attuale.

Inoltre, vorrei menzionare che sebbene questa non sia una "codifica" la domanda è relativa agli algoritmi e al design che IMHO sono argomenti molto importanti.

Grazie a tutti per le risposte finora.

Nelson Marmol

Risolviamo diversi problemi, ma il nostro approccio ad alcuni di essi potrebbe essere interessante per te.

Consentiamo al sistema di effettuare una "migliore ipotesi" e di fornire agli utenti un feedback regolare su qualsiasi di quelle ipotesi che sembrano sbagliate.

Per applicarlo all'inventario, potresti avere 3 campi:

inventory_received
inventory_sold
estimated_on_hand

Quindi, potresti eseguire un processo (ogni giorno?) sulla falsariga di:

SELECT * 
FROM   Inventory
WHERE  estimated_on_hand != inventory_received - inventory_sold

Ovviamente, ciò si basa sul fatto che gli utenti guardino questo avviso e facciano qualcosa al riguardo.

Inoltre, potresti avere una funzione per reimpostare l'inventario in qualche modo, aggiornando inventario_venduto / ricevuto o magari aggiungendo un altro campo "inventario_adeguamento", che potrebbe essere positivo o negativo.

... solo alcuni pensieri. Spero sia utile.

Autorizzato sotto: CC-BY-SA insieme a attribuzione

Non affiliato a StackOverflow