Sql: Pre inserimento di entità relazionali vs "creazione lazy" delle entità

1

Ho le seguenti entità nel mio database (è semplificato):

  • Studente (id)
  • StudentCourse (id, student_id, course_id)
  • Corso (id)
  • Lezione (id)
  • LessonCourse (id, lesson_id, course_id)
  • StudentCourseLesson (id, student_id, course_id, lesson_id, completato)

  1. Lo studente può iscriversi a un corso (l'entità StudentCourse è in fase di creazione).

  2. Ogni corso è composto da lezioni e una lezione può far parte di più corsi.

  3. Lo studente è in grado di contrassegnare una lezione specifica in un corso specifico come "completata".

Il problema:

Le entità StudentCourseLesson devono essere pre-inserite nel database nel momento in cui l'utente si iscrive al corso con i valori predefiniti (centinaia di righe), o dovrebbero essere create al volo, nel momento in cui l'utente inizierà qualche interazione con lo specifico lezione del corso specifico (come segnarne uno come completato)?

Cosa posso pensare:

  • La prima opzione rende il mio codice server più pulito (non c'è bisogno di verifiche se l'entità esiste nel database) e rende tutto nel database esistente nello "stato ben definito" ma fa sì che gli inserimenti massicci aumentino ad ogni iscrizione, e anche se potrebbe non essere un problema in questo caso, posso vedere come può diventare rapidamente un problema come modello di progettazione in alcune relazioni più complesse (scarsa scalabilità?).
  • La seconda opzione distribuisce il lavoro del database in tempo di più, ma sembra molto brutto. È fondamentalmente una "creazione pigra" delle entità. Cosa fare se dovrò visualizzare l'elenco delle lezioni con lo stato "completato"? Potrei anche crearli tutti a questo punto.

Personalmente mi chiamo verso la prima opzione nel mio caso d'uso, ma mi chiedo se non mi sia mancato nulla considerando questo problema. Come dovrebbe essere gestito questo tipo di relazioni?

    
posta Luken 19.01.2018 - 11:44
fonte

2 risposte

0

È una buona domanda - ci sono complessi compromessi per la creazione di entità di intersezione in anticipo rispetto a pigramente.

Creazione anticipata:

  • È più pulito per i join attraverso le entità di intersezione
  • Salva le complessità se è possibile aggiornare le entità di intersezione in più posizioni

Creazione pigra:

  • ha benefici se i corsi non sono immutabili. Se desideri aggiungere lezioni, la creazione anticipata dovrebbe mantenere più percorsi di codice per la creazione di entità di intersezione

  • Salva spazio e distribuisce il lavoro (anche se potrebbero essere entrambi banali)

Nota comunque che non devi creare l'entità intersezione per unirla. Puoi sfruttare i join esterni per "unirti" a e attraverso le righe che non esistono In un join esterno, la comprensione della tabella di guida del join diventa importante.

Vorrei inclinarmi alla creazione pigra di entità di intersezione e utilizzare join esterni per le query. Il modo in cui andrai dipenderà dai requisiti specifici dell'applicazione, nonché dalla familiarità con cui vuoi ottenere i join esterni.

    
risposta data 04.02.2018 - 19:48
fonte
0

Il primo caso ha più senso per me, se e solo se un corso è immutabile nel punto in cui possono essere inseriti corsi per studenti associati.

Se un corso può essere modificato oltre quel punto - ad esempio, i LessonCourses associati possono essere inseriti e cancellati - la creazione pigra sarà meno disordinata (anche se ancora abbastanza disordinata).

    
risposta data 19.01.2018 - 12:52
fonte

Leggi altre domande sui tag