Inventardatenbank Design [geschlossen]

https://stackoverflow.com/questions/287097

08-07-2019
|

Frage

Dies ist eine Frage nicht wirklich über „Programmierung“ (ist in jeder beliebigen Sprache oder Datenbank nicht spezifisch), sondern mehr von Design und Architektur. Es ist auch eine Frage des Typs „Was ist der beste Weg, X zu tun“. Ich hoffe, tut keinen Grund zu viel „religiös“ kontrovers diskutiert.

In der Vergangenheit habe ich Systeme entwickelt, die in der einen oder anderen, irgendeine Form von Inventar von Gegenständen halten (nicht relevant welche Elemente). Einige mit Sprachen / DB, die keine Transaktionen unterstützen. In den Fällen, entschied ich mich nicht Artikel Menge auf der Hand in einem Feld in dem Artikeldatensatz zu speichern. Stattdessen wird die Menge auf der Hand wird in Höhe von insgesamt Inventar erhalten berechnet - insgesamt Inventar verkauft. Dies hat fast keine Abweichungen im Inventar geführt wegen der Software. Die Tische sind korrekt indiziert und die Leistung ist gut. Es gibt einen Archivierungsprozess in Fall ist die Menge der Aufzeichnung zu beeinflussen Leistung beginnen.

Jetzt, vor einigen Jahren begann ich in dieser Firma zu arbeiten, und ich geerbt ein System, das Inventar verfolgt. Aber die Menge in einem Feld gespeichert. Wenn ein Eintrag registriert ist, wird die Menge empfangenen für das Element zu der Menge Feld hinzugefügt. Wenn ein Artikel verkauft wird, wird die Menge abgezogen. Dies hat zu Unstimmigkeiten geführt. Meiner Meinung nach ist dies nicht der richtige Ansatz, aber die bisherigen Programmierer hier schwören darauf.

Ich würde gerne wissen, ob es einen Konsens über ist, was ist der richtige Weg ist, ein solches System zu entwerfen. Auch, welche Ressourcen zur Verfügung stehen, gedruckt oder online, suchen Beratung zu diesem Thema.

Danke

Lösung

Ich habe beiden Ansätze in meinem derzeitigen Unternehmen gesehen und würde auf jeden Fall in Richtung der ersten anlehnen (Summen basierend auf Aktientransaktionen Berechnung).

Wenn Sie nur eine Gesamtmenge in einem Feld irgendwo speichern, haben Sie keine Ahnung, wie man zu dieser Zahl gekommen. Es gibt keine Transaktionshistorie und Sie können mit Problemen am Ende.

Das letzte System-I Titel Lager schrieb, indem jede Transaktion als Datensatz mit einer positiven oder negativen Menge zu speichern. Ich habe festgestellt, es funktioniert sehr gut.

Andere Tipps

Ich habe Vol 1 und Vol 2 und diese haben in der Vergangenheit sehr hilfreich gewesen.

Es hängt davon ab, Inventar-Systeme sind weit mehr als nur das Zählen Artikel. Zum Beispiel für Abrechnungszwecke, müssen Sie möglicherweise Buchwert des Inventars auf FIFO (First-in-First-out) Modell basierte kennen. Das kann nicht durch einfache berechnet werden „in Höhe von Inventar erhalten - insgesamt Inventar verkauft“ Formel. Aber ihr Modell könnte dies leicht berechnen, weil sie Buchwert ändern, wie sie gehen. Ich will nicht ins Detail gehen, weil dies nicht die Programmierung Problem ist aber, wenn sie von ihm schwören, vielleicht haben Sie nicht vollständig verstehen alle ihre Anforderungen haben sie aufzunehmen.

beide gültig sind, je nach den Umständen. Ersteres ist am besten, wenn folgende Bedingungen erfüllt sind:

die Anzahl der Elemente Summe ist relativ klein
gibt es nur wenige oder gar keine Ausnahmefällen zu prüfen (Erträge, Anpassungen, et al)
das Inventar Artikelmenge ist nicht sehr häufig benötigt

auf der anderen Seite, wenn Sie eine große Anzahl von Gegenständen, mehrere Ausnahmefälle haben, und häufigen Zugriff, wird es effizienter sein, die Artikelmenge zu halten

auch beachten, dass, wenn Ihr System Unstimmigkeiten hat dann es hat Fehler , die nach unten und eliminiert verfolgt werden sollte

Ich habe Systeme in beide Richtungen durchgeführt, und beide Wege können gut funktionieren - solange man nicht ignorieren die Fehler

Werfen Sie einen Blick auf die ARTS (Association for Retail Technology Standards) Datenmodell ( http://nrf-arts.org ). Es verwendet eine StockLedger Tabelle mit einem Datensatz jedes Element und Änderungen an der Bestandsaufnahme sind alle in InventoryJournalEntries verfolgt.

Es ist wichtig, das bestehende System und die Kosten und Risiken der Änderung es zu berücksichtigen. Ich arbeite mit einer Datenbank, die Inventar Art wie das Ihre tut speichert, aber es enthält Prüfungszyklen und speichert Anpassungen wie Quittungen. Es scheint gut zu funktionieren, aber alle Beteiligten ist gut ausgebildet, und das Lagerpersonal ist nicht gerade schnell neue Verfahren zu lernen.

In Ihrem Fall, wenn Sie suchen ein wenig mehr Tracking ohne die ganze db Struktur zu ändern, dann würde ich eine Tracking-Tabelle empfiehlt Zugabe (eine Art, wie von Ihrem ‚Geschäft‘ Lösung) und dann Änderungen melden Sie sich an das Inventar Niveau. Es sollte nicht zu schwer sein, die meisten Änderungen an der Lagerbestand zu aktualisieren, so dass sie auch eine Transaktionsaufzeichnung verlassen. Sie könnten auch eine periodische Aufgabe zur Sicherung der Bestands Ebene der Transaktionstabelle alle paar Stunden oder so hinzufügen, so dass selbst wenn Sie eine Transaktion verpassen Sie entdecken können, wenn die Änderung in einen früheren Zustand geschehen oder rückgängig zu machen.

Wenn Sie sehen möchten, wie eine große Anwendung dauert es, einen Blick auf SugarCRM , haben sie und Inventar Management-Modul, obwohl ich nicht sicher bin, wie es die Daten speichert.

Ich denke, das ist eigentlich eine allgemeine Best Practices Frage zu einem tun (relativ) teuer Zählung jedes Mal, wenn Sie insgesamt brauchen vs. dass jedes Mal etwas ändert zählen tun, dann die Zählung in einem Feld Speichern und Lesen dieses Feld, wenn Sie müssen insgesamt.

Wenn ich nicht Transaktionen verwenden könnte, würde ich mit der Live-Zählung geht jedes Mal, wenn ich insgesamt benötigt. Wenn Transaktionen zur Verfügung stehen, wäre es sicher die Bestandsaktualisierungsvorgänge und die Speicherung des Wieder gezählt Gesamt innerhalb derselben Transaktion durchzuführen, was die Genauigkeit der Zählung gewährleisten (obwohl ich nicht sicher bin, das mit mehreren Benutzern arbeiten würde schlagen die Datenbank).

Aber wenn die Leistung ist nicht wirklich ein großes Problem (und moderne Datenbanken sind gut genug, um in den Zeilen zu zählen, die mich über diese selten sogar Angst) Ich habe gerade mit der Live-Zählung jedes Mal bleiben würde.

ich für die erste Möglichkeit entscheiden würde, wobei

die Menge auf der Hand berechnet in Höhe von insgesamt Inventar erhalten - insgesamt Inventar verkauft

Der richtige Weg, IMO.

EDIT: Ich möchte auch in allen Aktien Verluste / Schäden in das System Faktor, aber ich bin sicher, Sie haben das überdachte

Ich habe auf Systemen gearbeitet, die dieses Problem vor lösen. Ich denke, die ideale Lösung ist eine vorberechnete Spalte, die Ihnen das Beste aus beiden Welten bekommt. Ihr Gesamt wäre ein Feld irgendwo, so dass keine teueren Lookups, aber es kann nicht mit dem Rest Ihrer Daten nicht mehr synchronisiert sind (die Datenbank wird die Integrität). Ich erinnere mich nicht, welche RDMSs vorberechneten Spalten unterstützen, aber wenn Sie nicht über Transaktionen, die möglicherweise auch nicht verfügbar sein.

Sie könnten möglicherweise gefälschte vorberechneten Spalten (sehr effektiv ... Ich sehe keinen Nachteil) mit Trigger. Sie würden vermutlich obwohl Transaktionen benötigen. IMHO, Datenintegrität zu halten, wenn Sie diese Art von kontrollierten Denormalisierung tun ist die einzige legitime Verwendung für einen Trigger.

Django-Inventar mehr ausgerichtet auf das Anlagevermögen, sondern vielleicht einige geben Ideen.

IE: ItemTemplate (Klasse) -> ItemsOnHand (Beispiel)

ItemsOnHand kann auf mehr ItemTemplates verbunden sein können; Beispiel Drucker & Tintenpatronen ist erforderlich. Auf diese Weise kann auch Reorder Punkte für jeden ItemOnHand einzustellen.

Jeder ItemsOnHand zu InventoryTransactions verbunden ist, ermöglicht dies für eine einfache Revision. Berechnung der tatsächlichen auf der Hand Elemente aus tausend invetory Transaktionen zu vermeiden, werden Checkpoints verwendet, die nur ein Gleichgewicht + ein Datum. Zur Berechnung der Elemente auf der Hand Abfrage den letzten Checkpoint zu finden und starten Sie das Hinzufügen oder Subtrahieren Artikel den aktuellen Saldo der Elemente zu finden. Definieren Sie neue Checkpoints in regelmäßigen Abständen.

ich einen Nutzen zu haben, die beiden Spalten sehen kann, aber ich folge nicht den Teil über Diskrepanzen - Sie scheinen, dass die beiden Spalten werden impliziert (in und out) ist weniger anfällig für Abweichungen als eine einzige Spalte ( Strom). Warum das?

Ist ein oder zwei Spalten nicht mit, ich meinte, was mit „in Höhe von Inventar erhalten - insgesamt Inventar verkauft“ ist so etwas wie folgt aus:

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

dann

Qunatity_on_hand = inventory_received - inventory_sold

Bitte beachten Sie, dass ich stark vereinfacht dies und meine erste Erklärung. Ich weiß, es gibt viel mehr zu Inventar, das nur den Überblick über Mengen zu halten, aber in diesem Fall, dass das Problem waren liege und was wir wollen beheben. An diesem Punkt ist der Grund, es zu ändern ist preciselly die Kosten für die Unterstützung, die von der aktuellen Design-Probleme verursacht.

Ich wollte auch erwähnen, dass, obwohl dies nicht eine „Codierung“ ist Frage zu Algorithmen, verwandt ist und Design, die IMHO sind sehr wichtige Themen.

Vielen Dank allen für Ihre Antworten so weit.

Nelson Marmol

Wir lösen verschiedene Probleme, aber unser Ansatz von ihnen einige vielleicht interessant für Sie sein.

Wir lassen das System eine „best guess“, machen und die Nutzer regelmäßig Feedback über eine dieser Vermutungen geben, die falsch aussehen.

dies Inventar anwenden zu können, könnten Sie drei Felder haben:

inventory_received
inventory_sold
estimated_on_hand

Dann könnten Sie einen Prozess ausführen (täglich?) Entlang der Linien von:

SELECT * 
FROM   Inventory
WHERE  estimated_on_hand != inventory_received - inventory_sold

Natürlich beruhen diese auf den in dieser Ausschreibung suchen und etwas dagegen zu tun.

Auch könnten Sie eine Funktion haben, Inventar, wie einige zurücksetzen, entweder durch inventory_sold Aktualisierung / empfangenen oder vielleicht das Hinzufügen eines weiteren Feld „inventory_adjustment“, die positiv oder negativ sein könnte.

... nur ein paar Gedanken. Hoffe, es ist hilfreich.

Lizenziert unter: CC-BY-SA mit Zuschreibung

Nicht verbunden mit StackOverflow