Datenbanktabellen-Design zum Speichern von Ja-, Nein- und Mengenantworten auf Fragen

Question

Ich habe eine Tabelle, die Antworten auf Checklistenfragen speichert, wobei die Checklisten das Format yes, no, not applicable, or resolved haben.

Table: CHECKLIST_ANSWER 
     ATTRIBUTE_ID PK, FK 
     CHECKLIST_INSTANCE_ID PK, FK 
     TOGGLE_VALUE (1=yes, 2=No, 3=n/a, 4=was a no then it was resolved) 
     FAIL_REASON 

attribute_id ist ein Fremdschlüssel zu einer Tabelle von Fragen, das heißt Was the part measured within some tolerance?

Jetzt möchte ich eine Checkliste modellieren, die Menge Antworten speichern würde, dh How many incorrect dimensions were found on the drawing?

ich zuversichtlich, dass ich speichern kann diese Fragen in meiner gleichen Tabelle wie die Ja/Nein/Na-Typ-Attribute, aber kann ich die gleiche Tabelle verwenden, um die Menge Wert zu speichern? Sollte ich eine neue Spalte sagen QUANTITY_VALUE? Und dann wäre entweder QUANTITY_VALUE oder TOGGLE_VALUE in Abhängigkeit von dem Attribut null.

Table: CHECKLIST_ANSWER 
     ATTRIBUTE_ID PK, FK 
     CHECKLIST_INSTANCE_ID PK, FK 
     TOGGLE_VALUE (1=yes, 2=No, 3=n/a, 4=was a no then it was resolved) 
     QUANTITY_VALUE 
     FAIL_REASON 

Das Ziel dieser Datenbank-Anwendung ist Papier zu bewegen und Excel Checklisten online und erfassen in Oracle effizientere Sammlung von Metriken zu geben, zu liefern und dann besser aggreagation der Eingänge. Frage ich nach Ärger auf der Straße, indem ich zwei in einen Tisch mische? Oder sollte ich eine Tabelle erstellen, CHECKLIST_QTY_ANSWER

Answer 1

Wenn Sie viele Optionen haben, erstellen Sie normalerweise eine separate Tabelle, nur mit einer ID und Beschreibung (oder Name). Um diese beiden Tabellen zu verbinden, fügen Sie ein Feld in die CHECKLIST_ANSWER-Tabelle ein und definieren es als Fremdschlüssel, der auf die ID (Primärschlüssel) der neuen Tabelle verweist, die ich zuerst erwähnt habe.

Hoffe, dass es klar ist :)

Answer 2

Wenn ich Ihre Frage richtig verstanden beraten Sie suchen, wie die neue Art der Antworten in Ihrem Schema speichern?

Da dies eine neue Art von Antwort ist, müssen Sie angeben, dass sich das Format der Daten jetzt von Ihrem Antworttyp y/n/na unterscheidet. Sie können dies tun, indem Sie in Ihrer Tabelle CHECKLIST_ANSWER eine weitere Tabelle CheckListAnswerType und eine FK hinzufügen.

Allerdings könnte Ihre CHECKLIST_INSTANCE_ID leicht darauf hinweisen, dass dies eine Art Checkliste ist, die einem bestimmten Antwortmuster folgt. Ich bin mir nicht sicher über den Rest Ihres Schemakaufs Sie könnten eine CHECKLIST_INSTANCE Tabelle haben, die seinen Antworttyp spezifiziert ...

Ihr TOGGLE_VALUE konnte einem numerischen Schema für Ihre neuen Antworttypen und mit dem a vorher erwähnten CheckListAnswerType Sie folgen könnte und müsste dies immer berücksichtigen, wenn Sie die Daten abfragen, um sicherzustellen, dass Sie nicht den falschen Antworttyp für den Fragekontext ausgewählt haben, so dass Sie keinen Ja-Wert erhalten haben, während Sie nach Ihrer How many incorrect dimensions were found on the drawing? Antwort suchen.

Ich würde denken, dass alles in Ordnung wäre, bis Sie beginnen möchten, Antworten eines anderen Datentyps zu speichern. Dann wäre es Zeit, das Schema neu zu gestalten.

TL; DR: Wenn Sie denselben Datentyp für Antworten verwenden, können Sie das vorhandene Schema (Spalte) wiederverwenden, während Sie eine Möglichkeit hinzufügen, die Antwort- oder Frage/Antwort-Typen zu unterscheiden genau abfragen. Wenn Sie andere Datentypen in TOGGLE_VALUE speichern möchten, implementieren Sie dazu neue Schemaobjekte. Versuchen Sie nicht, andere Datentypen in das aktuelle Schema zu zwingen, wenn Sie es vermeiden können. Auch wenn Sie dies tun, erwägen Sie, TOGGLE_VALUE umzubenennen, da es nicht mehr ein Toggle darstellt. answerValue könnte besser zum neuen Design passen.

Answer 3

Ich sehe kein Problem mit dem Hinzufügen der neuen Spalte zu Ihrer vorhandenen Tabelle. Ich würde eine Prüfbedingung einschließen, die entweder TOGGLE_VALUE oder QUANTITY_VALUE null sein sollte (aber nicht beides).

Es gibt keinen guten Grund, eine zweite, fast identische Tabelle zu erstellen, in der nur eine einzelne Spalte variiert. Nach meiner Erfahrung führt dies zu mehr Problemen als die Single-Table-Lösung (es ist praktisch eine Einladung, dynamisches SQL zu verwenden).

Ich würde die vorhandene Spalte definitiv nicht verwenden (wie in einer anderen Antwort vorgeschlagen), da dies die Verwendung eines Fremdschlüssels auf dem Toggle-Wert verhindern würde.