Progettazione del database: riferimento circolare ma creato dinamicamente

Naviga le tue risposte
1

Sto provando a progettare un database per questo caso:

  1. Le assegnazioni hanno vettori, la relazione è 1: N
  2. Le assegnazioni hanno invii, la relazione è 1: N
  3. Le presentazioni hanno esecuzioni, la relazione è 1: N
  4. Ogni esecuzione ha un vettore.

Logica aziendale

  1. l'insegnante crea compiti e definisce i vettori di test
  2. studente carica la sua soluzione, quindi viene creato un record nelle submission
  3. Dopo aver compilato correttamente l'invio, l'invio viene eseguito con i vettori di test definiti. Ogni esecuzione è un record nelle esecuzioni (un'esecuzione per vettore).

Quindi, dopo un'esecuzione corretta, viene creato un riferimento circolare, ma se la compilazione fallisce, non viene creato alcun record nelle esecuzioni. Il collegamento tra i vettori e le esecuzioni è necessario per il processo di calcolo del punteggio, dove è l'output di riferimento dai vettori rispetto all'output delle esecuzioni.

Quindi, nel mio caso, il riferimento circolare non è persistente, ma dipende dal runtime, quindi è design errato?

    
posta eXPi 22.03.2014 - 15:39
fonte

1 risposta

0

La parte difficile è che i database relazionali non si preoccupano della direzione della relazione o delle dipendenze circolari. Nel modello a oggetti ci interessa.

Definisci le tue relazioni "ha a" e quindi estrai una delle classi con un'interfaccia per rompere la dipendenza circolare. Ad esempio:

  • Assegnazione aggregati TestVector (cioè ha una collezione di)
  • L'invio ha un incarico
  • L'esecuzione ha un invio
  • Esecuzione aggregati ExecutionStep (interfaccia)
  • Vector è un ExecutionStep (interfaccia)

Vedi come l'Esecuzione si riferisce a un ExecutionStep astratto piuttosto che a un Vettore concreto? Questo interrompe la dipendenza circolare, perché ora puoi definire altre cose per l'esecuzione da eseguire senza modificare il modello a oggetti.

(Tuttavia, guardandolo ora, non hai bisogno della chiave esterna dall'esecuzione al vettore, perché puoi ottenerla con un join di Execution - > Submission - > Assignment - > Vector.)

...

Quando scrivi le classi per modellare queste tabelle, allora hai una dipendenza dal codice circolare, che è male. Quindi puoi interrompere la dipendenza dal codice con un'interfaccia, ma questo è un problema separato dalla progettazione del database.

Nel design del database , il motivo Execution - > Il vettore è problematico è che duplica Execution - > Invio - > Assegnazione - > Vettore. Quindi dovresti assicurarti che rimangano sincronizzati.

A meno che:

  • stai duplicando i dati come ottimizzazione delle prestazioni e amp; conosci i rischi

  • vuoi che l'esecuzione rifletta i vettori coinvolti quando è in esecuzione

Cioè, diciamo che un incarico aggiunge un nuovo vettore. Tutte le esecuzioni esistenti non vedranno quel nuovo vettore, perché indicano già la loro lista di vettori. Ma potrebbe essere una buona cosa, perché sta dicendo "Quando è stata eseguita questa Esecuzione, ha usato questi Vettori, anche se un incarico potrebbe aver aggiunto o rimosso Vettori da allora".

Pensavo che questi artefatti non sarebbero cambiati; che sono tutti immutabili. Ma potrebbe essere una cattiva ipotesi. Quindi potrei sbagliarmi: il riferimento da Execution a Vector potrebbe non essere ridondante. Sapresti la risposta a questo meglio di me.

    
risposta data 22.03.2014 - 15:58
fonte

Leggi altre domande sui tag

La ricerca binaria sembra superiore, perché il comitato di C ++ ha ancora trovato nella libreria dell'algoritmo? La valutazione del cortocircuito è una conseguenza della chiamata per nome?