我有 2 个数据库表：团队和游戏。
就这个问题而言，我们正在处理足球（足球）球队和比赛。
每场比赛只有两支球队，通常是一支主队和一支客队，尽管偶尔两支球队都可以保持中立。
我的问题是我是否应该使用 Games 表中的 2 个外键（home_team_id、away_team_id）来表示这种数据关系，还是应该使用与 games_teams 表的多对多关系来链接两者，在这种情况下我需要还要存储球队是主队还是客队，这似乎有点矫枉过正。
更令人困惑的是，我在 KohanaPHP 中使用了 ORM 库，这些库期望 fk 被称为 team_id 或链接表仅包含 2 列。如果您在 KohanaPHP 中遇到过这个问题，请留下回复，否则任何一般性建议也非常感谢。
只需使用两列，否则您只需要在连接器表中对其进行限定。这不像是一颗沉睡的定时炸弹，突然有一天你会发现你需要一个真正的多对多。
在我看来，2 列在这里非常合适。任何游戏只能有两个团队这一事实通过具有两列反映在您的数据库模式中。通过引入链接表，您引入了单场比赛可能有 2 个主队、2 个客队的可能性，并且您需要额外的验证以确保这种情况永远不会发生。通过将事物与两列隔离，您的架构固有地强制执行数据完整性。
如果您希望能够在数据库服务器上固定“Xth Normal Form”徽章，那么它可能应该被视为多对多，否则，我应该认为您将减少查询开销，减少 1 个表每次你想要一些有用的数据时，你都会加入。
在标准化方面：是的。只有一对多或多对多被分解为一个或多个一对多关系。
但实际上，如果我要保存像 GENDER 这样的东西。我真的需要一个多状态和一个附加的日期时间戳吗？
令人惊讶的答案是肯定的——但只有当我出于商业原因需要跟踪性别变化时——对于大多数实际目的来说，答案是否定的。
我会保留一张有两个键的表 - 除非有商业原因这样跟踪它。
根据您如何抽象它，我会说足球比赛必须有两支球队，在这种情况下，在 Game 表中包含列不仅更方便，而且更正确。
我什至可以想象 team id 是 Game 主键的自然组成部分。
完全认为您不应该为此设置单独的表格。程序员更容易，数据库更容易。很高兴考虑一下如果，但听起来你已经有了。不要以为标准化始终是解决所有问题的方法。
我尊重另一个人的回答，即使用两列是最佳选择，但是，您提到您正在使用 Kohana 中的 ORM 库。通过在游戏表中使用两列，您将失去多对多关系的 ORM 功能。如果您设置了 games_teams 数据透视表，您可以执行以下操作：
$game = ORM::factory('game', 1); // 1 is the game id
然后您可以循环浏览该游戏中的团队：
foreach ($game->teams as $team) {
// do stuff with $team
}