Inventory Database Design

Question

Ich habe mehrere Beispiele für eine Inventardatenbank gefunden. Aber ich suche etwas ein bisschen anders. Ich arbeite mit SQL.

Ich muss die Werkzeuge im Auge behalten. Mitarbeiter können Werkzeuge auschecken und das Inventar für dieses Werkzeug wird reduziert und eine solche Transaktion wird in einer Tabelle (checked_out) aufgezeichnet. Einfach zu weit.

Wenn der Mitarbeiter das Werkzeug oder die Werkzeuge zurückgibt, hat der Mitarbeiter die Wahl. Er kann das Werkzeug entweder in das Inventar zurückgeben. Immer noch ziemlich einfach. Oder er könnte das Werkzeug gebrochen zurückbringen und es wegwerfen, mit anderen Worten, es auf den Mülltisch aufnehmen. Oder er könnte das Werkzeug in den Nachschärfebehälter legen und es auf den Nachschärftisch aufzeichnen. Hier werde ich verwirrt.

Answer 1

Klingt, als ob Sie einen Status in der Inventurtabelle benötigen. Zum Beispiel kann ein Datensatz für ein beliebiges Werkzeug ein Statusfeld haben, das ein Fremdschlüssel in der Tabelle "Status" ist. Der Status Tabelle könnte wie folgt aussehen:

ID  Description 
----------------------- 
1  Available 
2  In Use 
3  Broken 

... etc.

Ihr Inventar Tabelle könnte wie folgt aussehen:

id  status_id  description 
------------------------------------- 
1  2   Hammer 
2  1   Hammer 
3  3   Hammer 
4  1   Saw 
5  3   Saw 

Dann, wenn Sie Inventar zu berechnen, zeigt nur Datensätze, bei denen Ein Werkzeug hat den Status "1" für Verfügbar. Sie können auch Abfragen für die Verwaltung ausführen, um anzuzeigen, wie viele Werkzeuge "beschädigt" sind. Planen Sie das Löschen dieser Datensätze nach der ordnungsgemäßen Abrechnung der fehlerhaften Tools oder bewahren Sie sie für historische Daten auf.

Vermeiden Sie unbedingt separate Tabellen für die Disposition einer Entität in der Datenbank. Verwenden Sie ein "Flag" -Feld (d. H. Status_id), damit Sie einer Anwendung neue Status hinzufügen können, ohne dass Sie neue Tabellen unendlich hinzufügen müssen.

Answer 2

Ihre Einstellung falsch ist, sollten Sie nicht eine separate Tabelle für Müll haben, abgemeldeten und nachschärfen-sind. Dies sind nur die Zustände, in denen das Werkzeug gefunden werden kann.

Was Sie wollen, ist eine Datenbank, die diese zwei Tabellen enthält, die die Daten vorgeschlagen von Hardcode in his solution beherbergen wird:

Inventory 
----- 
id (PK) 
description 
status_id (FK -> Statuses) 

Statuses 
---------- 
id (PK) 

Answer 3

I hard Schema mögen, aber es könnte eine bessere Übereinstimmung der Situation sein wird modelliert um einen Ort statt eines Status zu speichern (in jedem Fall würde ich die Verwendung des Wortes "Status", das so allgemein ist, dass es meangingless ist, abhalten). Der Ort ist wirklich, was hier verfolgt wird, und könnte sogar verwendet werden, um anzuzeigen, wer der aktuelle Besitzer des Artikels ist, wenn er ausgecheckt ist. Ich denke, dass körperliche Kondition getrennt gehalten werden sollte, wenn sie überhaupt verfolgt werden soll. Dies würde feinere Grade von Bedingungen ermöglichen, die auf Benutzerfeedback oder Mitarbeiterbeobachtung basieren.

(Reaktion 2 Kommentar)

ich erwarten würde, dass Sie einen Tisch haben würden, die einzelnen Bewegungen von Werkzeugen (von Ort A nach Ort B zu einem bestimmten Zeitpunkt von Person Z) und eine weitere Aufnahme zu Zeichnen Sie eine Zusammenfassung auf höherer Ebene oder den aktuellen Standort auf. Vieles hängt davon ab, ob die Tools einzeln anhand der Seriennummer identifiziert wurden. In diesem Fall würden Sie sie einzeln nachverfolgen oder nur eines von mehreren Tools desselben Typs, die nicht einzeln identifiziert werden. Dies würde bestimmen, ob Sie 5 Transaktionen (eine für jedes Werkzeug) oder eine Transaktion mit 5 Werkzeugen aufzeichnen.Sie können nur zusammenfassen als "5 Werkzeuge ausgecheckt" oder Sie könnten sagen "diese einzelnen Werkzeuge sind derzeit an diesen Standorten".