Progettazione del database dei questionari: in che modo è meglio?

Ho UNA pagina HTML lunga, diverse serie di domande divise in piccole sezioni (circa 15 sottosezioni in una pagina), il totale delle domande sono circa 100 domande: varia da input, scelta multipla, caselle di controllo, pulsanti di opzione, area di testo, e caricamento di file. Una domanda potrebbe contenere molte risposte ottenute da un gruppo di caselle di controllo, un gruppo di elenco di selezione, un gruppo di selezione multipla o tutti combinati in un'unica risposta. Ho pensato di utilizzare questo progetto di database qui sotto, ma ho scoperto di recente che dopo tutto non è un buon approccio.

1. Un cliente può avere solo una serie di domande: un cliente per 100 domande.
2. Per il vecchio approccio non tengo domande nel database ma assegno invece come costante nella codifica PHP. Il problema è che devo confrontare la domanda in PHP per farlo sincronizzare con la risposta nel database. Se una domanda fosse stata modificata / cancellata / spostata da PHP, mi sarei sicuramente perso per abbinarla con la risposta nel database del questionario. Soluzione migliore?
3. Potrei essere in grado di mantenere più risposte ottenute da più elementi nella forma in un campo come una risposta? Come posso recuperare questo campo e visualizzarlo di nuovo per la visualizzazione dei clienti sul modulo?
4. Quale opzione in basso dovrei scegliere?

OPZIONE 1: Old Approach (1 tabella)

TABELLA: questionario

• ID (PK)
• Identificativo del cliente
• Stato
• A1
• A2
• A3
• .
• .
• .
• A100

OPZIONE 2: Nuovo approccio (2 tabelle)

TABELLA: domanda

• QID (PK)
• Domanda (varchar)

TABELLA: Risposta

• AIUTI (PK)
• Identificativo del cliente
• QID (int)
• Risposta (varchar)

O OPZIONE 3?

Sicuramente non codificare il questionario. Utilizzare un database relazionale o file xml. Propongo le seguenti tabelle

• Questionnaire: Descrizione generale del questionario. Titolo, nome del sondaggio, data di rilascio del questionario, versione e così via.

• Section: Sezioni del questionario. Numero della sezione, titolo della sezione, descrizione.

• Question: Le domande appartenenti a una sezione. Numero della domanda, testo della domanda, descrizione, tipo di domanda (testo, scelta multipla, ecc.).

• Question_Choice: Le possibili risposte appartenenti a una domanda corrispondente alle singole caselle di controllo, pulsanti di opzione e così via. Testo della scelta, numero della scelta, ordine.

• Respondent: Le persone che rispondono alle domande. Dati personali, numero utente.

• Interview: Interviste o test o sondaggi (a seconda della natura del questionario) appartenenti a un rispondente e un questionario. Se un rispondente può sempre rispondere a un solo questionario (o se il sondaggio è anonimo), questa tabella è obsoleta e può essere unita alla tabella dei rispondenti. Data del colloquio (o data del test o del sondaggio), intervistatore (se applicabile).

• Answer: Risposte appartenenti a un colloquio (o intervistato, vedi sopra) e una domanda. Rispondi al testo (per domande sul tipo di testo), scelta (per i pulsanti di opzione).

• Answer_Choice: Scelte appartenenti a una risposta e una domanda_Choice quando è possibile verificare più scelte.

Questo è un approccio molto normalizzato; tuttavia, è possibile decidere di concatenare le scelte in una stringa o di memorizzarle come pattern di bit o semplificarle in qualche altro modo a seconda delle esigenze.

Hai bisogno di alcuni tavoli,

1 - Le domande (ID domanda, tipo di input, visibile, tipo di domanda, testo della domanda, risposte attese ....)

2 - Le risposte (ID domanda, ID utente, ID attività, risposta ....)

3 - Gli utenti (ID utente, nome utente ......)

4 - Una tabella per contenere un'attività di domande / risposte (ID attività, dati / ora, ID utente)

Potresti anche avere una tabella che specifica le domande che dovrebbero essere applicate per ogni attività - raggruppate per utente o forse una raccolta di domande. Le chiavi esterne / primarie saranno le colonne che hanno lo stesso nome in più tabelle e dovrebbero essere indicizzate.

Se usi questa struttura, dovresti essere in grado di aggiungere una domanda o un utente o modificare una risposta senza dover cambiare il tuo schema o il codice di presentazione - assicurati che il codice di presentazione sia creato dinamicamente in fase di esecuzione - devi solo aggiungere un record nel posto appropriato.

Inizialmente, questo approccio potrebbe richiedere più tempo rispetto a un approccio codificato, ma sarà molto più semplice da mantenere poiché sarà necessario solo modificare i dati per cambiare comportamento.

(Un suggerimento, per creare il tuo livello di presentazione, avrai bisogno di una query che ottenga le domande appropriate da visualizzare, quindi passa in rassegna questo set di risultati e chiama un metodo per renderizzare una domanda sullo schermo, i metodi da scegliere sono appropriati per il presentazione di tale domanda [casella di testo, gruppo radio, ecc.])