Database
 sql >> Database >  >> RDS >> Database

Un modello di database per un sondaggio online. Parte 4

In questo articolo finale di una serie in quattro parti, completo la progettazione di un database di sondaggi online per fornire flessibilità per sondaggi multipli, riutilizzo delle domande, risposte a scelta multipla, ordinamento delle domande, salti condizionali nel sondaggio in base alle risposte e controllo sull'accesso degli utenti ai sondaggi tramite gruppi di proprietari di sondaggi.

Introduzione

Nella conclusione della parte 3 di questa serie di articoli, ho menzionato che avrei aggiunto funzionalità più avanzate in questo articolo. Queste funzionalità avanzate sono:

  • amministrazione dei sondaggi
  • rapporti e analisi

Come promemoria, ecco il modello dopo la parte 3:



Amministrazione

Il mio obiettivo nell'amministrazione dei sondaggi è consentire la gestione di un sondaggio e delle relative informazioni da parte di un gruppo. Quindi consentirò a un utente amministrativo di definire gruppi di utenti che possono gestire congiuntamente un sondaggio online e le sue domande. Il proprietario del gruppo può definire quali funzioni possono svolgere gli altri utenti del gruppo; ad esempio, Jeff può modificare ed eliminare sondaggi e domande, ma Joe può solo visualizzare sondaggi e domande, ma non modificarli o eliminarli.

Una cosa che potresti notare è che gli utenti sono separati dai partecipanti al sondaggio. Naturalmente, un utente potrebbe anche rispondere a un sondaggio, ma vorrei tenerlo separato in modo da poter richiedere meno informazioni a un rispondente che a un utente (ad esempio, ho rimosso il campo della password da un rispondente in modo che è più facile per le persone rispondere al sondaggio senza creare un login/account).

Fondamentalmente, per questa amministrazione, creerò tabelle per gruppi e utenti e i ruoli e le autorizzazioni o le azioni corrispondenti consentite. Ciò consente flessibilità anziché un collegamento hardcoded tra i ruoli e le azioni consentite da ciascun ruolo. Naturalmente, l'applicazione corrispondente deve essere creata per comprendere quale funzionalità è consentita da ciascuna autorizzazione e deve essere adattata quando vengono aggiunte nuove funzionalità, ma non sarà necessario modificare il design del database quando verrà aggiunta la funzionalità:verranno aggiunte nuove righe al tabella che collega i ruoli alle autorizzazioni.

Potresti anche notare che ho usato una lunghezza dispari per l'email colonna sull'user e respondent tabelle e un valore dispari per il ip_address colonna per il respondent; 254 è la lunghezza massima che può avere un indirizzo email secondo le definizioni RFC, mentre 45 è la lunghezza massima che può avere un indirizzo IPv6 (con tunneling IPv4).




Inoltre, aggiungerò un link dal group tabella al survey tabella da cui i collegamenti vanno a tutte le tabelle associate (question_order , survey_response , conditional_order , question_type , response_choice ). In questo modo, quando il gruppo viene eliminato, posso avvisare il proprietario del gruppo che tutte le informazioni corrispondenti verranno eliminate.

Preferisco questo approccio di collegare i dati della tabella a qualcosa di diverso dall'utente specifico anziché non collegare i dati a nulla. Se non abbiamo collegato i dati a nulla (né gruppo né utente) come mi sembrava di fare nelle parti precedenti di questa serie di articoli, allora avremo la sfida di "ripulire" i dati obsoleti quando un utente viene eliminato dal sondaggio online applicazione. Collegandolo al concetto più astratto di "gruppo", diventa quindi possibile per il proprietario riassegnare la proprietà del gruppo e tutti i dati corrispondenti (sondaggi, domande, risposte, ecc.) a un altro membro del gruppo, se necessario.

Design formale

Quindi estendiamo l'ERD che è stato creato nelle altre parti di questa serie di articoli.




Ho colorato in giallo le tabelle che sono state create nell'articolo della Parte 1, ho colorato in arancione le tabelle aggiunte nella Parte 2, ho colorato in verde le tabelle aggiunte nella Parte 3 e le tabelle appena aggiunte in azzurro in modo che sia più facile vedi le aggiunte Il colore non è stato aggiunto alle colonne e alle chiavi esterne che sono state aggiunte in questo articolo finale, quindi dovresti confrontare il modello attuale con quello precedente della Parte 3 per vedere le differenze.

Rapporti e analisi

Abbiamo sufficienti informazioni che possono essere estratte dalle tabelle per produrre diversi report.

Ad esempio, a quali domande è stata data risposta in un modo particolare ("nel sondaggio 7, quante volte gli intervistati hanno risposto "Sì" alla domanda 10?"). Questo livello di informazioni probabilmente va bene per i rapporti di base sulle risposte ai sondaggi.

Possiamo anche estrarre il tempo impiegato dagli intervistati per rispondere a un particolare sondaggio ("sul sondaggio 5, il tempo medio trascorso nel sondaggio era di 13 minuti"); anche in questo caso, queste potrebbero essere informazioni utili in modo che i proprietari di un sondaggio possano modificare le domande del sondaggio in modo che non richiedano più tempo di quello che un intervistato tipico è disposto a spendere o di ciò che il geometra ha "promesso" agli intervistati (ad es. "questo sondaggio dovrebbe durare tra 5 e 10 minuti”). So che quando qualcuno mi dice che dovrei finire in meno di 10 minuti e 15 minuti dopo sto ancora arrovellando le domande, allora mi arrabbio e generalmente non sono disposta a rispondere a un altro sondaggio da parte loro.

Sulla base degli indirizzi IP degli intervistati, potremmo effettuare una ricerca inversa per avere un'idea approssimativa di dove provengono gli intervistati o almeno da dove sembra provenire il loro indirizzo IP quando hanno risposto. Tieni presente che queste informazioni non sono del tutto affidabili poiché le persone potrebbero connettersi tramite VPN o altri meccanismi che dissociano il loro indirizzo IP dalla loro posizione fisica.

Possiamo anche estrarre il modo in cui le domande ricevono risposta dai primi intervistati rispetto a come hanno risposto i secondi intervistati. Questo potrebbe presentare un punto di vista interessante per il tuo sondaggio:€" ad esempio, le persone desiderose che hanno risposto al sondaggio prima hanno risposto in modo diverso rispetto alle persone che non erano così desiderose e hanno risposto al sondaggio in seguito?

In questa fase, penso che questi report saranno sufficienti e che non sono necessarie analisi più avanzate, poiché l'informazione più importante è ovviamente il report di base di quali risposte sono state fornite a ciascuna domanda in un sondaggio. Se hai bisogno di analisi più avanzate, considera quali sono i tuoi requisiti e in che modo i dati esistenti o le nuove strutture possono supportare tali analisi.

Conclusione

E il gioco è fatto. Non affermerò che questo sia il design per il database di sondaggi online ideale, ma questo soddisferà le mie esigenze in termini di flessibilità:sondaggi multipli, riutilizzo delle domande, risposte a scelta multipla, ordinamento delle domande, salti condizionali nel sondaggio basato su risposte e controllo sull'accesso degli utenti ai sondaggi tramite gruppi di proprietari di sondaggi.

Come ho fatto in ogni parte precedente di questa serie di articoli, farò notare che potresti avere altri requisiti. Identifica le tue esigenze e implementa o adatta ciò di cui hai bisogno. Credo fermamente nel riutilizzo e non nel reinventare la ruota.


Se desideri che riprogettiamo o espandiamo questo modello in base alle esigenze della tua applicazione, faccelo sapere. Possiamo aiutarti.


Un modello di database per un sondaggio online –€“ l'intera serie

Parte 1 Parte 2 Parte 3 Parte 4