Progettazione del database per un sondaggio [chiuso]

Devo creare un sondaggio in cui le risposte sono archiviate in un database. Mi sto solo chiedendo quale sarebbe il modo migliore per implementarlo 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 e, eventualmente, domande che potrebbero contenere più di una risposta (vale a dire controllare tutte le risposte pertinenti).

Ho escogitato due possibili soluzioni:

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

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

2. L'altra cosa a cui ho pensato è stata la creazione di una tabella delle domande e una tabella delle risposte. La tabella delle domande conterrebbe tutte le domande per il sondaggio. La tabella delle risposte conterrebbe le risposte individuali del sondaggio, ciascuna riga collegata a una domanda.

   Un semplice esempio:

   tblSurvey : SurveyID

   tblQuestion : QuestionID, SurveyID , QuestionType, Question

   tblAnswer : AnswerID , UserID , QuestionID , Answer

   tblUser : UserID, UserName

   Il mio problema con questo è che potrebbero esserci tonnellate di risposte che renderebbero la tabella delle risposte piuttosto grande. Non sono sicuro che sia fantastico quando si tratta di esibizioni.

Gradirei idee e suggerimenti.

Penso che il tuo modello n. 2 vada bene, tuttavia puoi dare un'occhiata al modello più complesso che memorizza domande e risposte preconfezionate (risposte offerte) e consente di riutilizzarle in diversi sondaggi.

- Un sondaggio può avere molte domande; una domanda può essere (ri) utilizzata in molti sondaggi.
- È possibile offrire una risposta (prefabbricata) per molte domande. Una domanda può avere molte risposte offerte. Una domanda può avere diverse risposte offerte in diversi sondaggi. È possibile offrire una risposta a diverse domande in diversi sondaggi. Esiste una risposta "Altro" predefinita, se una persona ne sceglie un'altra, la sua risposta viene registrata in Answer.OtherText.
- Una persona può partecipare a molti sondaggi, una persona può rispondere a una domanda specifica in un sondaggio una sola volta.

Il mio design è mostrato di seguito.

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

Lo script e il file mysql workbench.mwb sono disponibili anche su
https://github.com/durrantm/survey

Sicuramente l'opzione # 2, anche io penso che potresti avere una svista nello schema corrente, 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 prestabilito di risposte tra le quali 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 si adatta molto bene. Non è necessario utilizzare un modulo normale inferiore semplicemente per risparmiare spazio.

Come regola generale, la modifica dello schema in base a qualcosa che un utente potrebbe cambiare (come 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 sapere cosa si sta affrontando prima di immergersi. Avere solo una tabella di "risposte" per ogni sondaggio significa che aggiungere o rimuovere domande è potenzialmente molto costoso ed è molto difficile eseguire analisi in modo indipendente dalla domanda.

Penso che il tuo secondo approccio sia il migliore, ma se sei sicuro che avrai molte preoccupazioni su scala, una cosa che ha funzionato per me in passato è un approccio ibrido:

1. Creare tabelle di risposta dettagliate per archiviare le risposte per domanda come descritto in 2. In genere questi dati non verrebbero richiesti direttamente dall'applicazione, ma verrebbero utilizzati per generare dati di riepilogo per le tabelle dei rapporti. Probabilmente vorrai anche implementare una qualche forma di archiviazione o espulsione per questi dati.
2. Se necessario, crea anche la tabella delle risposte da 1. Questo può essere usato ogni volta che gli utenti vogliono vedere una semplice tabella per i risultati.
3. Per qualsiasi analisi che deve essere eseguita a scopo di reporting, pianificare i lavori per creare ulteriori dati di riepilogo basati sui dati da 1.

Questo è assolutamente molto più lavoro da implementare, quindi non lo consiglierei a meno che tu non sappia per certo che questa tabella si imbatterà in enormi problemi di scala.

Il secondo approccio è il migliore.

Se si desidera normalizzarlo ulteriormente, è possibile creare una tabella per i tipi di domanda

Le cose semplici da fare sono:

• Posizionare il database e accedere al proprio disco, non tutti su C come impostazione predefinita
• Crea il database in base alle necessità in modo da non avere pause mentre il database cresce

Abbiamo avuto tabelle di registro nella tabella di SQL Server con 10 di milioni di righe.

No 2 sembra a posto.

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

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

Naturalmente, è necessario specificare quale database si sta utilizzando e volumi stimati.

Sembra abbastanza completo per un sondaggio smiple. Non dimenticare di aggiungere una tabella per "valori aperti", in cui un cliente può fornire la propria opinione tramite una casella di testo. Collegare quella tabella con una chiave esterna alla risposta e posizionare gli indici su tutte le colonne relazionali per le prestazioni.

Il numero 2 è corretto. Utilizzare il design corretto fino a quando non si rileva un problema di prestazioni. La maggior parte dei RDBMS non avrà 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, dovresti andare bene. Il tuo secondo schema mi sta bene.

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.

È possibile scegliere di memorizzare l'intero modulo come stringa JSON.

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