Fragebogendatenbankdesign - welcher Weg ist besser?

Ich habe EINE lange HTML-Seite, mehrere Sätze von Fragen, die in kleine Abschnitte unterteilt sind (ca. 15 Unterabschnitte auf einer Seite). Die Gesamtzahl der Fragen beträgt ca. 100 Fragen: variiert von Eingabe, Mehrfachauswahl, Kontrollkästchen, Optionsfeldern, Textfeldern, und Datei hochladen. Eine Frage kann viele Antworten enthalten, die entweder aus einer Gruppe von Kontrollkästchen, einer Gruppe von Auswahllisten, einer Gruppe von Mehrfachauswahllisten oder aus allen zu einer Antwort zusammengefasst wurden. Ich dachte, ich würde dieses Datenbankdesign unten verwenden, fand aber in letzter Zeit heraus, dass es doch nicht der gute Ansatz ist.

1. Ein Kunde konnte nur einen Fragensatz haben: Ein Kunde pro 100 Fragen.
2. Für den alten Ansatz behalte ich keine Frage in der Datenbank, sondern weise stattdessen eine Konstante in der PHP-Codierung zu. Das Problem ist, dass ich die Frage in PHP vergleichen muss, um sie mit der Antwort in der Datenbank zu synchronisieren. Wenn eine Frage in PHP geändert / gelöscht / verschoben worden wäre, würde ich mich definitiv verirren, um sie mit der Antwort in der Fragebogendatenbank abzugleichen. Bessere Lösung?
3. Kann ich mehrere Antworten, die aus mehreren Formularelementen stammen, als eine Antwort in einem Feld speichern? Wie kann ich dieses Feld abrufen und es für die Kundenanzeige im Formular erneut anzeigen?
4. Für welche Option unten soll ich mich entscheiden?

OPTION 1: Alter Ansatz (1 Tabelle)

TABELLE: Fragebogen

• ID (PK)
• Kundennummer
• Status
• A1
• A2
• A3
• .
• .
• .
• A100

OPTION 2: Neuer Ansatz (2 Tabellen)

TABELLE: Frage

• QID (PK)
• Frage (varchar)

TABELLE: Antwort

• AID (PK)
• Kundennummer
• QID (int)
• Antwort (varchar)

Oder OPTION 3?

Codieren Sie Ihren Fragebogen auf keinen Fall hart. Verwenden Sie eine relationale Datenbank oder XML-Dateien. Ich schlage folgende Tabellen vor

• Questionnaire: Allgemeine Beschreibung des Fragebogens. Titel, Name der Umfrage, Veröffentlichungsdatum des Fragebogens, Version usw.

• Section: Die Abschnitte, aus denen ein Fragebogen besteht. Nummer des Abschnitts, Abschnittsüberschrift, Beschreibung.

• Question: Die zu einer Sektion gehörenden Fragen. Nummer der Frage, Fragentext, Beschreibung, Fragentyp (Text, Multiple Choice, etc.).

• Question_Choice: Die möglichen Antworten zu einer Frage, die den einzelnen Kontrollkästchen, Optionsfeldern usw. entsprechen. Text der Wahl, Wahlnummer, Bestellung.

• Respondent: Die Personen, die die Fragen beantworten. Persönliche Daten, Benutzernummer.

• Interview: Interviews oder Tests oder Umfragen (abhängig von der Art des Fragebogens), die zu einem Befragten und einem Fragebogen gehören. Wenn ein Befragter immer nur einen Fragebogen beantworten kann (oder wenn die Umfrage anonym ist), ist diese Tabelle veraltet und kann mit der Befragten-Tabelle zusammengeführt werden. Interviewdatum (oder Testdatum oder Umfragedatum), Interviewer (falls zutreffend).

• Answer: Antworten zu einem Interview (oder Befragten, siehe oben) und einer Frage. Antworttext (für Textfragen), Auswahl (für Optionsfelder).

• Answer_Choice: Auswahlmöglichkeiten, die zu einer Antwort und einer Frage gehören, wenn mehrere Auswahlmöglichkeiten ausgewählt werden können.

Dies ist ein sehr normalisierter Ansatz. Sie können sich jedoch dafür entscheiden, die Auswahl in einer Zeichenfolge zu verketten oder sie als Bitmuster zu speichern oder sie auf andere Weise zu vereinfachen, je nach Ihren Anforderungen.

Sie brauchen ein paar Tische,

1 - Die Fragen (Fragen-ID, Eingabetyp, sichtbar, Fragentyp, Fragentext, erwartete Antworten ....)

2 - Die Antworten (Frage-ID, Benutzer-ID, Aktivitäts-ID, Antwort ....)

3 - Die Benutzer (Benutzer-ID, Benutzername ......)

4 - Eine Tabelle für eine Frage / Antwort-Aktivität (Aktivitäts-ID, Daten / Zeit, Benutzer-ID)

Möglicherweise möchten Sie auch eine Tabelle haben, in der die Fragen aufgeführt sind, die für jede Aktivität angewendet werden sollen - entweder gruppiert nach Benutzer oder möglicherweise eine Fragensammlung. Die Fremd- / Primärschlüssel sind die Spalten, die in mehreren Tabellen denselben Namen haben und indiziert werden sollten.

Wenn Sie diese Struktur verwenden, sollten Sie in der Lage sein, eine Frage oder einen Benutzer hinzuzufügen oder eine Antwort zu ändern, ohne Ihr Schema oder Ihren Präsentationscode ändern zu müssen. Stellen Sie sicher, dass der Präsentationscode zur Laufzeit dynamisch erstellt wird. Sie müssen lediglich einen Datensatz hinzufügen an der richtigen Stelle.

Die Entwicklung dieses Ansatzes kann anfangs länger dauern als bei einem fest programmierten Ansatz, ist jedoch viel einfacher zu warten, da Sie nur Daten ändern müssen, um das Verhalten zu ändern.

(Ein Tipp, um Ihre Präsentationsebene zu erstellen, benötigen Sie eine Abfrage, die die entsprechenden Fragen anzeigt. Durchlaufen Sie dann diese Ergebnismenge und rufen Sie eine Methode auf, um die Frage auf dem Bildschirm zu rendern Präsentation dieser Frage [Textfeld, Radiogruppe usw.])