Nel caso di un rapporto a due-a-molti dati essere trattato come molti-a-molti?

Question

Ho 2 tabelle del database: Squadre e giochi

.

Ai fini di questa domanda, abbiamo a che fare con squadre di calcio (calcio) e giochi.

Ogni gioco ha esattamente 2 squadre, in genere una squadra di casa e una squadra di sbarco anche se a volte entrambe le squadre possono essere neutrali.

La mia domanda è se dovrei rappresentare questa relazione i dati utilizzando 2 chiavi esterne nella tabella Games (home_team_id, away_team_id) o se devo usare una relazione molti-a-molti con un tavolo games_teams per collegare i due, nel qual caso avrei bisogno di memorizzare anche se la squadra è stata la casa o squadra di casa sembra un po 'eccessivo.

Per aumentare la confusione, io sto usando le librerie ORM in KohanaPHP e questi mi aspetto un fk di essere chiamato team_id o una tabella di collegamento a contenere solo 2 colonne. Se avete esperienza con questo problema in KohanaPHP quindi si prega di lasciare una risposta, altrimenti qualche consiglio generale è anche molto apprezzato.

Answer 1

Se si vuole essere in grado di bloccare un badge "X forma normale" sul server di database, allora dovrebbe probabilmente essere trattato come molti-a-molti, in caso contrario, credo si riducono i costi generali di query con 1 meno tabella che si sta solo andando a unirsi a tutti volta che si desidera alcuni dati utili fuori.

Answer 2

Basta usare le due colonne, altrimenti avresti solo bisogno di qualificarsi nella tabella falegname. Non è come se questa è una bomba a tempo di sonno e improvvisamente un giorno scoprirete è necessario disporre di un vero e proprio molti a molti.

Answer 3

2 colonne è perfettamente appropriato qui a mio parere. Il fatto che ci può solo eventualmente essere due squadre per qualsiasi gioco si riflette nel vostro schema di database da avere due colonne. Con l'introduzione di una tabella di collegamento, si introduce la possibilità che un singolo gioco potrebbe avere 2 squadre di casa, 2 via squadre, e si avrebbe bisogno di ulteriori convalide per garantire che questo scenario non si verifica mai. Mantenendo le cose isolate alle due colonne, lo schema impone di per sé l'integrità dei dati.

Answer 4

In termini di normalizzazione: Sì. C'è solo un uno-a-molti o una relazione molti-a-molti che viene suddiviso in una o più relazioni uno-a-molti.

Ma realisticamente parlando, se dovessi salvare qualcosa come il genere. Avrei davvero bisogno di un multi-stato e un timbro datetime allegato al presente?

La risposta sorprendente è sì - ma solo se ho bisogno di tenere traccia delle modifiche di genere per motivi di lavoro -. Per scopi più pratici la risposta è NO

Mi tengo un tavolo con due chiavi -. A meno che non ci sia un motivo di business per tenere traccia come tale

Answer 5

A seconda di come è stata estratta, io direi che la partita di calcio deve avere due squadre, in questo caso avere le colonne della tabella gioco non è solo più conveniente, è più corretto.

Potrei anche immaginare di essere parti naturali del id squadra della chiave primaria del gioco.

Answer 6

Completamente pensare che non dovrebbe avere un tavolo separato per questo. Più facile sul programmatore, più facile per il DB. Buono a pensare al cosa se, ma suona come hai già. Non farsi prendere a pensare che la normalizzazione è sempre la strada da percorrere per tutto.

Answer 7

Io rispetto le risposte degli altri nel dire che con le due colonne è la scelta migliore, tuttavia, si menziona che si sta utilizzando la libreria ORM in Kohana. Utilizzando due colonne della tabella giochi si perde l'ORM caratteristiche per molti-a-molti. Se si imposta una tabella games_teams pivot, è possibile effettuare le seguenti operazioni:

$game = ORM::factory('game', 1); // 1 is the game id

Allora è possibile scorrere le squadre in quel gioco:

foreach ($game->teams as $team) {
// do stuff with $team
}