Nella parte 1 di questa serie di articoli, abbiamo discusso un progetto di base per un sondaggio online. Nella conclusione di quell'articolo, ho menzionato che la parte 2 coprirebbe funzionalità più avanzate per il nostro sondaggio come:
- Diversi tipi di domande come domande a scelta multipla
- Ordine condizionale delle domande in un sondaggio o, in altre parole, la possibilità di un percorso condizionato attraverso il sondaggio
- Amministrazione dei sondaggi
- Rapporti e analisi
Iniziamo estendendo la funzionalità per supportare diversi tipi di domande.
Tipi di domande
Nella parte 1 di questa serie di articoli, utilizzavamo solo domande a risposta aperta che consistevano in una domanda e una risposta. In questo articolo definiremo diversi tipi di domande come domande polari (sì-no) e domande a scelta multipla . Ogni domanda sarà associata a un tipo. Per le domande polari, consentiremo solo sì/no come risposta, ma, in futuro, potremmo consentire variazioni come vero/falso. Le domande che non sono aperte avranno possibili risposte tra le quali il rispondente può scegliere.
In futuro, aggiungeremo domande che richiedono una risposta valutata. Ad esempio, "Quanto ti piace la progettazione di database; valuta tra 1 e 100 (con 1 che indica che ti piace molto poco e 100 che indica che ti piace immensamente)?"
Entità e relazioni
Per i diversi tipi di domande nel sondaggio, estenderò l'area "domande" con tipi e scelte di risposta.
Idealmente, vorrei creare una chiave esterna tra le risposte effettive e le possibili risposte per domande a scelta multipla (response_choice) per garantire l'integrità dei dati. Ciò funzionerebbe se tutte le domande avessero opzioni di risposta e le domande aperte non fossero consentite. Poiché ho bisogno di supportare le domande aperte, dovrò garantire l'integrità delle risposte nel codice dell'applicazione.
Design formale
Dobbiamo estendere l'ERD creato nella parte 1 di questa serie di articoli. Come prima, userò Vertabelo, un modellatore di database online. Se non hai ancora un account Vertabelo, puoi registrarti per una prova gratuita qui.
Farò un commento; scoprirai che generalmente uso numeri rotondi come 100 o 1000 per definire la lunghezza dei campi varchar; Non sto suggerendo che queste siano necessariamente delle dimensioni appropriate, ma piuttosto la uso come abbreviazione invece di lasciare la lunghezza indefinita. Quando si utilizza questo modello, regolare le lunghezze in base alle proprie esigenze particolari. Ad esempio, permetterai a un rispondente di digitare una risposta molto, molto lunga a una domanda aperta o li limiterai, diciamo, a 1000 caratteri? Ciò può dipendere dall'applicazione che stai creando per utilizzare il database, poiché potrebbe avere limitazioni sulla lunghezza dei campi.
Aggiungo una tabella di tipo_domanda collegata alla domanda:questi potrebbero avere un nome "aperto", "sì-no", "scelta multipla" e, in futuro, "valutazione". Per le domande a scelta multipla, ogni domanda dovrebbe avere response_choices da cui scegliere.
Potresti anche usarlo per implementare domande polari, ma penso che sia eccessivo. Un'altra soluzione sarebbe quella di collegare response_choice a question_type, in modo che la riga question_type "yes-no" sia collegata alle righe response_choice "Sì" e "No", ma ancora una volta, non credo sia necessario, ma potresti se vuoi possibilità multilingue. Dovresti quindi includere un campo per la lingua del rispondente all'interno della tabella response_choice o gestire l'internazionalizzazione sull'interfaccia utente.
Ho colorato le tabelle create nella parte 1 in giallo e le tabelle appena aggiunte in arancione in modo che sia più facile vedere le aggiunte.
Conclusione
Ora abbiamo iniziato ad implementare i miglioramenti che sono stati discussi nella parte 1 di questa serie di articoli.
Nel prossimo articolo, aggiungerò ulteriore supporto per le seguenti funzionalità:
- Ordine condizionale delle domande in un sondaggio
- Gestione dei sondaggi
- Rapporti e analisi
