Wie modelliert Open/Closed Status in einer Datenbank?

Question

Stellen Sie sich vor, ich habe eine Tabelle Bestellungen mit Spalten OrderID (PK), CustomerID, CustomerOrderN und so weiter. Jetzt muss ich eine Möglichkeit hinzufügen, um Bestellungen zu "schließen" und einen Grund anzugeben, warum der Auftrag geschlossen wird (zum Beispiel "angebotener Preis ist zu hoch für den Kunden", "nicht verfügbar", "Kunde gebeten, den Auftrag zu schließen").

Frage 1. Was wäre der beste und korrekte Weg, dies im Datenbankdesign zu implementieren?

Ich denke, der beste Weg ist, Closed-Spalte, die Null (wenn Reihenfolge geöffnet ist) und wenn nicht null (d. H. Wenn Reihenfolge geschlossen ist), dann der Wert verweist auf eine andere Tabelle OrderCloseReasons.

Frage 2. Was ist, wenn ich bereits :) eine boolesche Spalte in Orders Tabelle geschlossen, und jetzt muss ich implementieren Möglichkeit, Gründe für das Schließen angeben. Ich kann nicht viel umgestalten, weil das System nicht schon so klein ist, so dass es schwierig ist, das Datenbankschema umzuformen. Was wäre der beste Weg, die Möglichkeit hinzuzufügen, Gründe für die Schließung in einem solchen Fall zu spezifizieren?

Ich denke, wenn ich nur CloseReasonID Spalte auf Bestellungen Tabelle hinzufügen wird es nicht gut sein. Aber ich bin mir nicht sicher.

Vielen Dank im Voraus.

Answer 1

Wenn Sie eine Reihe von spezifischen schließen Gründe, die Sie verwenden wollen, und wenn Sie in der Lage sein müssen, Abfragen durchführen, basierend auf einer bestimmten Art von Nähe Grund (sagen wir alle von Grund X bekommen), dann, was Sie vorschlagen, ist eine gute Idee - null oder eine enge Grund ID.

Auf der anderen Seite, wenn Sie keine Suche usw. benötigen, können Sie einfach eine Spalte geschlossen haben und eine andere Spalte, die beschreibt, warum sie geschlossen wurde.

Answer 2

Ich würde eine StatusCode-Spalte (wahrscheinlich int-Datentyp) und eine separate Tabelle mit einem StatusCode (int) und StatusCodeDescription (varchar) empfehlen. Das gibt Ihnen mehr Flexibilität, wenn Sie oder Ihre Endbenutzer später über einen anderen möglichen Status nachdenken.

Answer 3

Persönlich würde ich die Nachschlagetabelle tun, wie Sie vorschlagen, aber nennen Sie es Status. Ich würde den Fremdschlüssel für die Status-Tabelle in der Orders-Tabelle ein int, nicht null mit einem Standardwert von 1 sein.

Dann die Datensätze in der Status-Tabelle wäre (1) Offen, (2) geschlossen Grund eins (3) Geschlossener Grund zwei usw. Auf diese Weise können Sie einer Enumeration in einer höheren Ebene zuordnen, ohne dass Sie etwas Besonderes in Ihren gespeicherten Prozeduren vornehmen müssen. Das heißt, Sie müssen nur die Status-ID in Ihre SELECT-Anweisung aufnehmen, statt sich mit der Behandlung der Null als einer Sache und der Lookup-Werte als einer anderen herumschlagen zu müssen.

Answer 4

Das Zusammenführen von Null und Grund in eine Nullable-Textspalte ist keine gute Idee, da es von anderen Programmierern oder sogar von Ihnen nach einigen Tagen nicht leicht lesbar ist.

Mit zwei Spalten eine entweder Boolean oder Status-Code wie von David angegeben, und separate Spalte für Grund. Dies gibt Ihrem Design mehr Lesbarkeit.

Aber ich werde einen Schritt voraus und Best Practice in Finanz-Software ist bereits im Audit-Trail gebaut haben, weil ich sicher ..

wissen möchte „Wer hat den Befehl geschlossen?“ "Um wie viel Uhr war es geschlossen?" "Wurde es wieder geöffnet?"

Der Audit-Trail besteht meist aus einer anderen Tabelle zum Beispiel

OrderAudit -> AuditID -> OrderID -> ChangeMadeBy -> ChangeDateTime -> ChangeColumn -> Change

Welche gibt die volle Kontrolle darüber, wer was mit dieser Bestellung gemacht hat und wann.

Answer 5

Eine zusätzliche Tabelle, die den nahen Grund für nur diese Bestellungen enthält, die geschlossen sind.

Es verletzt nicht 1NF, weil Sie keine Nullen in das Datenbankschema einführen, und Sie haben die absolutste Garantie, dass Ihre Änderungen keine Auswirkungen auf existierendes Zeug haben (was Sie in diesem Fall eindeutig angegeben haben)).

EDIT

Siehe z.B. "Was erste Normalform wirklich bedeutet" am Datum der Datenbank: Schriften 2000-2006 (Springer-Verlag, 2006). Möglicherweise auch als eigenständiges Papier im Internet zu finden.

Und von "Einführung in Datenbanksysteme", 8ed. : "Eine relvar ist genau dann in 1NF, wenn jedes Tupel in jedem zulässigen Wert dieser relvar genau einen Wert für jedes Attribut enthält." (und null kann möglicherweise kein Wert sein, weil es nicht gleich selbst ist).