Domanda / risposta per più utenti - Come dovrei progettarlo?

Un utente può richiedere molti set di domande , in momenti diversi o anche più di una volta - penso che tu abbia bisogno di una nuova classe qui per memorizzare:

(a) L'associazione di un utente con un gruppo di domande (quiz?), possibilmente in un momento specifico, e

(b) Le risposte selezionate da Utente per quel particolare Gruppo di domande .

Prenderò in considerazione una nuova classe, creata in base ai dati contenuti in un Set di risposte e contenente un nuovo campo chiamato, ad esempio, Chosen_Answer. In questo modo, la classe Sets of Answers rimane pulita, autonoma e, soprattutto, esiste indipendentemente di un particolare utente, quindi non è più necessario duplicare le copie. Quando un utente prende una serie di domande, si crea una nuova istanza di questa nuova classe in cui tenere le proprie risposte.

Poiché sembra che le domande e l'insieme di possibili risposte siano le stesse per tutti gli utenti, direi che va bene se condividi gli stessi dati con tutti gli utenti. Puoi usare la composizione per questo.

L'unico dato che varia in base alle tue descrizioni è la risposta selezionata dall'utente per ogni domanda. Come tale, un utente può avere un'altra struttura di dati di raccolta per memorizzare la risposta selezionata per domande, un po 'come

class User{
  private final List<Question>; 
  private final Map<Question, Answer> answers;

  public User(List<Question> questions){
      //shared by all users
      this.questions = questions;
      //an instance per user
      this.answers = new HashMap<>();
  }
}

Quando si tratta di archiviazione, la mappa delle risposte sarà probabilmente solo una tabella (o documento, file, archivio, ecc.) contenente gli ID delle domande e l'ID della risposta selezionata per un determinato utente.

+-----------------+
| selected_answer |
+-----------------+
| user_id  <pk>   |
| quest_id <pk>   |
| ans_id   <pk>   |
+-----------------+

Così facendo, evita la ripetizione sia in memoria che in archivio.

Quando progettate un DB, potreste voler mantenerlo normalizzato I.e. evitare i duplicati in modo che le query di aggiornamento vengano eseguite più velocemente e in un modo più sicuro. Questo non è l'unico approccio in quanto potresti desalizzare le tue tabelle in modo che le query di lettura possano essere eseguite più velocemente (più adatto alla BI). Il punto è che non c'è giusto o sbagliato - entrambi vanno bene a seconda delle esigenze.

Per quanto riguarda il tuo caso - se le quantità di cui stiamo parlando qui non sono grandi, e le prestazioni non sono un problema, andrei con l'archiviazione solo una rappresentazione della risposta selezionata nel tuo oggetto utente (forse un id o un oggetto risposta ). Renderà le cose più facili e semplici. Le cose che dovresti considerare sono le operazioni CRUD e la loro frequenza: con quale frequenza cambi il testo di una risposta? Una domanda? Con quale frequenza cambia la risposta selezionata, se mai? E così via ..

Un'altra cosa: mantenere gli oggetti del tuo dominio sincronizzati con l'attuale design del db non è obbligatorio, quindi potresti averne uno normalizzato e l'altro de-normalizzato.