Se um dois-para-muitos dados sejam tratados como muitos-para-muitos?

Question

Eu tenho 2 tabelas de banco de dados: Equipes e Jogos

.

Para efeitos desta questão, estamos lidando com o futebol (soccer) equipes e jogos.

Cada jogo tem exatamente 2 equipes, geralmente uma equipa da casa e uma equipa da casa, embora, ocasionalmente, as duas equipes pode ser neutra.

A minha pergunta é se eu deveria representar este relacionamento de dados usando 2 chaves estrangeiras na tabela de Jogos (home_team_id, away_team_id) ou se eu deveria usar um relacionamento muitos-para-muitos com uma games_teams mesa para ligar os dois, caso em que Eu precisaria também armazenar se a equipe foi a equipe de casa ou fora e parece um pouco exagerado.

Para aumentar a confusão, eu estou usando as bibliotecas ORM em KohanaPHP e estes esperaria um fk a ser chamado team_id ou uma tabela link para conter apenas 2 colunas. Se você tem experiência com este problema em KohanaPHP então por favor deixe uma resposta, outra coisa qualquer conselho geral é também muito apreciado.

Answer 1

Se você quer ser capaz de fixar um crachá "Xth Forma Normal" no seu servidor de banco de dados, então provavelmente deve ser tratada como muitos-para-muitos, caso contrário, eu acho que você vai reduzir suas despesas gerais de consulta com 1 menos tabela que você está indo só para se juntar através de todas vez que você quer alguns dados úteis para fora.

Answer 2

Basta usar as duas colunas, caso contrário, você só precisa qualificá-lo na tabela de marceneiro. Não é como se isso é uma bomba de tempo de dormir e de repente um dia você vai descobrir que você precisa para ter um verdadeiro muitos para muitos.

Answer 3

2 colunas é perfeitamente apropriado aqui, na minha opinião. O fato de que não só pode, eventualmente, ser duas equipes para qualquer jogo é refletida no seu esquema de banco de dados por ter duas colunas. Com a introdução de uma tabela de ligação, você introduz a possibilidade de que um único jogo poderia ter 2 equipas da casa, 2 equipas de distância, e você precisaria de uma validação adicional para garantir que este cenário nunca ocorre. Ao manter as coisas isoladas para as duas colunas, o esquema impõe inerentemente integridade dos dados.

Answer 4

Em termos de normalização: Sim. Há apenas um um-para-muitos ou muitos-para-muitos que será dividido em um ou mais de um-para-muitos relacionamentos.

Mas, realisticamente falando, se eu fosse para salvar algo como GÊNERO. Será que eu realmente preciso de um multi-estado e um carimbo de data e hora anexado a este?

A resposta surpreendente é sim - mas apenas se eu precisar para acompanhar as mudanças de gênero por razões comerciais -. Para a maioria dos efeitos práticos, a resposta é NÃO

Gostaria de manter uma tabela com duas chaves -. A menos que haja uma razão comercial para segui-lo como tal

Answer 5

Dependendo de como você ter abstraído, eu diria que jogo de futebol deve ter duas equipes, caso em que ter as colunas na tabela de jogo não é apenas mais conveniente, é mais correto.

Eu poderia até imaginar ser partes naturais do id equipe da chave primária de jogo.

Answer 6

Totally acho que você não deve ter uma tabela separada para isso. Mais fácil para o programador, mais fácil no DB. Bom pensar sobre o que ifs, mas parece que você já tem. Não fique de pensar Pego que a normalização é sempre o caminho a percorrer para tudo.

Answer 7

Eu respeito as respostas do outro em dizer que o uso de duas colunas é a melhor escolha, no entanto, você menciona que você está usando a biblioteca ORM em Kohana. Usando duas colunas na tabela de jogos que você perde as características ORM para muitos-para-muitos relacionamentos. Se você configurar uma tabela games_teams pivô, você pode fazer o seguinte:

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

Em seguida, você pode percorrer as equipes em que jogo:

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