我一直在对这个问题做一些研究,但仍然未能作出令人满意的决定。
这个问题离我最近,但对我的处境仍然没有帮助。
Large Number of Columns in MySQL Database
我基本上是在创建一个“谁会赢得一场战斗”的网站,以解决长期以来蝙蝠侠与超人风格的争论,用户可以投票决定他们认为谁会赢。
用户可以选择提交一个“斗士”到网站,然后将随机匹配到每一个其他斗士,供未来用户投票。
很明显,我想保留所有匹配项的统计信息,以便向用户显示。
现在我要一张叫“让我说”的桌子。这将存储主键、名称、描述等信息,但不会存储战斗结果。
至于存储战斗结果,我可以看到两个选项。
选项A:为每个战士创建一个表,以计算他们相对于其他战士的得票数主键。
选项B:创建一个大型投票表,该表的列数和行数将由战斗机的主键索引。然后,例如,为了获得Fighter1对Fighter4的统计数据,我会查询第1行(Fighter1 PK1)第4列(对于Fighter4 PK4)以获得Fighter1对Fighter4的胜率,然后重复查询第4行(对于Fighter4的PK4)第1列以获得Fighter4对Fighter1的胜率。这张桌子显然会变得很大,当数百(千?)增加了个战士。
(希望不要太混乱!)
所以我想我的问题是,最好有数百个小表(当添加新的fighter时,这些表都需要添加列和行)。还是要一张大桌子?
我完全50/50与这个,所以请任何建议或其他方式,我可以实现这将是非常感谢。
提前谢谢。
编辑:很抱歉遗漏了这个。我心中的投票基本上可以算作每一位拳击手对另一位拳击手胜出的总票数。
最佳答案
在澄清之后,我将考虑
CREATE TABLE FightResults
(
Fighter1Id INT REFERENCES FIGHTERS(FighterId),
Fighter2Id INT REFERENCES FIGHTERS(FighterId),
Fighter1Votes INT,
Fighter2Votes INT,
CHECK (Fighter1Id < Fighter2Id ),
PRIMARY KEY (Fighter1Id,Fighter2Id)
)
每次比赛你都有一排。大猩猩对鲨鱼,狮子对老虎等等。检查和pk约束确保相同的匹配不会出现多次。
这确实假设战斗将有固定数量的参与者在2。如果情况不是这样,那么一个更灵活的模式是
CREATE TABLE Fight
(
FightId INT PRIMARY KEY,
/*Other columns with fight metadata*/
)
CREATE TABLE FightResult
(
FightId INT REFERENCES Fight(FightId),
FighterId INT REFERENCES FIGHTERS(FighterId),
Votes INT,
PRIMARY KEY (FightId,FighterId)
)
但这确实增加了查询的可能不必要的复杂性。
您可能还希望防止同一用户在同一比赛中进行多次投票。在这种情况下,你可以使用类似的东西(假设每次比赛有两名选手)
CREATE TABLE Fights
(
FightId INT PRIMARY KEY,
Fighter1Id INT REFERENCES FIGHTERS(FighterId),
Fighter2Id INT REFERENCES FIGHTERS(FighterId),
CHECK (Fighter1Id < Fighter2Id )
)
CREATE TABLE Votes
(
FightId INT REFERENCES Fights(FightId),
UserId INT REFERENCES Users(UserId),
Vote INT CHECK (Vote IN (1,2)),
PRIMARY KEY (FightId,UserId)
)
但出于业绩原因,可能会保留未规范化的投票总数。