Progettazione del database per un sondaggio

Devo creare un sondaggio in cui le risposte sono memorizzate in un database. Mi sto solo chiedendo quale sarebbe il modo migliore per implementare questo nel database, in particolare le tabelle richieste. Il sondaggio contiene diversi tipi di domande. Ad esempio: campi di testo per commenti, domande a scelta multipla ed eventualmente domande che potrebbero contenere più di una risposta (ovvero controllare tutte le risposte pertinenti).

Ho trovato due soluzioni possibili:

  1. Crea una tabella gigante che contenga le risposte per ogni invio di sondaggio. Ogni colonna corrisponderebbe a una risposta dal sondaggio. cioè SurveyID, Answer1, Answer2, Answer3

    Non penso che questo sia il modo migliore perché ci sono molte domande in questo sondaggio e non sembra molto flessibile se il sondaggio deve cambiare.

  2. L’altra cosa a cui pensavo era creare una tabella delle domande e una tabella delle risposte. La tabella delle domande dovrebbe contenere tutte le domande per il sondaggio. La tabella delle risposte conterrà le singole risposte del sondaggio, ciascuna riga collegata a una domanda.

      Un semplice esempio:

      tblSurvey : SurveyID

      tblQuestion : QuestionID, SurveyID , QuestionType, Question

      tblAnswer : ID risposta, ID utente , ID interrogativo , Risposta

      tblUser : UserID, UserName

      Il mio problema è che potrebbero esserci tonnellate di risposte che renderebbero enorme la tabella delle risposte. Non sono sicuro che sia così eccezionale quando si tratta di prestazioni.

    Apprezzerei qualsiasi idea e suggerimento.

    Penso che il tuo modello n. 2 sia a posto, tuttavia puoi dare un’occhiata al modello più complesso che memorizza domande e risposte preimpostate (risposte offerte) e consente di riutilizzarle in diversi sondaggi.

    – Un sondaggio può avere molte domande; una domanda può essere (ri) utilizzata in molti sondaggi.
    – Una risposta (pre-creata) può essere offerta per molte domande. Una domanda può avere molte risposte offerte. Una domanda può avere risposte diverse offerte in diversi sondaggi. Una risposta può essere offerta a diverse domande in diversi sondaggi. C’è una risposta predefinita “Altro”, se una persona sceglie un altro, la sua risposta è registrata in Rispondi. Altro testo.
    – Una persona può partecipare a molti sondaggi, una persona può rispondere a una domanda specifica in un sondaggio solo una volta.

    survey_model_02

    Il mio disegno è mostrato sotto.

    L’ultimo script di creazione è disponibile su https://gist.github.com/durrantm/1e618164fd4acf91e372

    Lo script e il file mysql workbench.mwb sono anche disponibili su
    https://github.com/durrantm/survey inserisci la descrizione dell'immagine qui

    Sicuramente l’opzione n. 2, inoltre penso che potresti avere una svista nello schema attuale, potresti volere un’altra tabella:

     +-----------+ | tblSurvey | |-----------| | SurveyId | +-----------+ +--------------+ | tblQuestion | |--------------| | QuestionID | | SurveyID | | QuestionType | | Question | +--------------+ +--------------+ | tblAnswer | |--------------| | AnswerID | | QuestionID | | Answer | +--------------+ +------------------+ | tblUsersAnswer | |------------------| | UserAnswerID | | AnswerID | | UserID | | Response | +------------------+ +-----------+ | tblUser | |-----------| | UserID | | UserName | +-----------+ 

    Ogni domanda avrà probabilmente un numero predefinito di risposte che l’utente può selezionare, quindi le risposte effettive verranno tracciate in un’altra tabella.

    I database sono progettati per archiviare molti dati e la maggior parte scala molto bene. Non è più necessario utilizzare una forma normale minore semplicemente per risparmiare spazio.

    Come regola generale, la modifica dello schema in base a qualcosa che un utente potrebbe modificare (ad esempio l’aggiunta di una domanda a un sondaggio) dovrebbe essere considerata abbastanza maleodorante. Ci sono casi in cui può essere appropriato, in particolare quando si ha a che fare con grandi quantità di dati, ma sai cosa ti stai immergendo prima di immergerti. Avere solo una tabella di “risposte” per ogni sondaggio significa che aggiungere o rimuovere domande è potenzialmente molto costoso ed è molto difficile fare analisi in modo agnostico.

    Penso che il tuo secondo approccio sia il migliore, ma se sei sicuro di avere un sacco di problemi di scala, una cosa che ha funzionato per me in passato è un approccio ibrido:

    1. Crea tabelle di risposta dettagliate per archiviare le risposte per domanda come descritto in 2. Questi dati non vengono generalmente interrogati direttamente dall’applicazione, ma verrebbero utilizzati per generare dati di riepilogo per le tabelle di rapporto. Probabilmente vorresti anche implementare qualche forma di archiviazione o espungimento di questi dati.
    2. Crea anche la tabella delle risposte da 1 se necessario. Questo può essere usato ogni volta che gli utenti vogliono vedere una tabella semplice per i risultati.
    3. Per qualsiasi analisi che deve essere eseguita a scopo di report, pianificare i lavori per creare ulteriori dati di riepilogo in base ai dati di 1.

    Questo è decisamente molto più lavoro da implementare, quindi non lo consiglierei molto a meno che non si sappia per certo che questo tavolo incontrerà preoccupazioni su vasta scala.

    Il secondo approccio è il migliore.

    Se vuoi normalizzarlo ulteriormente, puoi creare una tabella per i tipi di domande

    Le semplici cose da fare sono:

    • Inserire il database e accedere al proprio disco, non tutti in C come impostazione predefinita
    • Creare il database grande quanto necessario in modo da non avere pause durante la crescita del database

    Abbiamo avuto tabelle di registro in SQL Server Table con decine di milioni di righe.

    No 2 sembra a posto.

    Per una tabella con solo 4 colonne non dovrebbe essere un problema, anche con un buon numero di milioni di righe. Ovviamente ciò può dipendere dal database che si sta utilizzando. Se è simile a SQL Server, non sarebbe un problema.

    Probabilmente vorresti creare un indice nel campo QuestionID, nella tabella tblAnswer.

    Naturalmente, è necessario specificare il database che si sta utilizzando e i volumi stimati.

    Sembra abbastanza completo per un sondaggio falso. Non dimenticare di aggiungere una tabella per “valori aperti”, in cui un cliente può fornire la sua opinione tramite una casella di testo. Collega la tabella con una chiave esterna alla tua risposta e posiziona gli indici su tutte le colonne relazionali per ottenere prestazioni.

    Il numero 2 è corretto. Utilizzare la progettazione corretta fino a quando non si rileva un problema di prestazioni. La maggior parte degli RDBMS non ha problemi con una tabella stretta ma molto lunga.

    Avere una grande tabella di risposte, di per sé, non è un problema. Finché gli indici e i vincoli sono ben definiti, si dovrebbe andare bene. Il tuo secondo schema mi sembra buono.

    Dato l’indice corretto, la seconda soluzione è normalizzata e valida per un sistema di database relazionale tradizionale.

    Non so quanto sia enorme, ma dovrebbe contenere senza problemi un paio di milioni di risposte.

    È ansible scegliere di memorizzare l’intero modulo come stringa JSON.

    Non sono sicuro del tuo requisito, ma questo approccio potrebbe funzionare in alcune circostanze.