Chiavi esterne nulle e creazione di tabelle di join

-1

Non sono così esperto in modellazione sql e sto cercando input su questo perché è importante per me farlo bene. Uso il nucleo mssql e entityframework in un'app web core asp.net.

L'app funziona come strumento per iscrivere persone per vari test. È possibile creare un progetto e quindi aggiungere persone a cui si desidera testare questo progetto.

Ho una tabella di progetto (tabella 1) con molti projectassignments (tabella 2), che è una tabella di join. Questa tabella di join ha una persona (tabella 3) con molti progetti di assegnazione. Ho anche due tabelle (tabella 4 e 5) che rappresentano due test diversi che possono avere molti progetti di assegnazione.

Normalmente quando si crea un progetto lo si fa per assegnare le persone a un test, quindi l'altro testtable per questo compito sarebbe nullo. Sto pensando che le chiavi esterne sulla tabella di join per questi test dovrebbero essere valori nulle? è una buona scelta o potrebbero esserci delle implicazioni per farlo?

Project table
int ID
ICollection<ProjectAssignment> ProjectAssignments { get; set; }

ProjectAssignments table
int ID
int ProjectID
int PersonID
int Test1ID
int Test2ID

Person table
int ID
ICollection<ProjectAssignment> ProjectAssignments { get; set; }

Test1 table
int ID
ICollection<ProjectAssignment> ProjectAssignments { get; set; }

Test2 table
int ID
ICollection<ProjectAssignment> ProjectAssignments { get; set; }

Quando si utilizza l'app, è possibile creare molti progetti in modo che una persona possa avere di nuovo più di un progetto con lo stesso tipo di test. In questo modo, quando cerco progetti nel back-end, posso semplicemente creare un elenco di assegnazioni di progetto e ottenere le persone, i test e il progetto sulla stessa query:

query = _context
    .ProjectAssignments
    .Where( i => i.ID == id )
    .Include( p => p.Project )
    .Include( p => p.Person )
    .Include( t => t.Test1 )
    .ToList()
;

Ogni feedback è molto apprezzato!

    
posta Johan Herstad 26.04.2018 - 09:28
fonte

2 risposte

0

Se una chiave straniera può essere Null = opzionale, questo tipo di rinuncia all'idea di "chiave esterna".

In questo caso, penserei che la relazione dovrebbe essere definita al contrario - la tabella dell'oggetto "straniero" dovrebbe invece avere una colonna con l'ID del rispettivo oggetto principale. In questo modo, non può essere nullo.

Potrebbero esserci motivi di rendimento per ripristinarlo, ma solo se è davvero necessario.

    
risposta data 26.04.2018 - 17:53
fonte
-1

C'è solo un caso in cui dovresti avere un FK nullable ed è lì che una tabella si unisce a se stessa, cioè. una relazione genitore / figlio.

Nel tuo caso non hai bisogno di FK nullable, la tua confusione sta nel cercare di usare la tabella dei projectignign per fare due o più join.

Potresti invece aggiungere due nuove 'tabelle di join' o riconsiderare le tue relazioni non completamente chiare

project 
    id

projectAssignments
    id
    projectId
    personId

person
    id

test1Assignments
    projectAssignmentId
    test1Id

test2Assignments
    projectAssignmentId
    test2Id

test1
    id

test2
    id
    
risposta data 26.04.2018 - 18:16
fonte

Leggi altre domande sui tag