我正在设计的项目是针对我工作的公司所以我不得不考虑类似的情况,可能会有大致相同的问题(如果它是一个问题)。
右派让我们发明一项新运动。 “挖掘一致性”。一次最多可以有12人参加。计时器启动并持续2小时。玩家在他们面前有一个数字键盘,他们必须在计时器启动后10秒钟点击它,然后每十秒钟点击一次,直到计时器达到两小时标记。
我需要在这里设计的应用程序是记录这项相当沉闷的运动的统计数据。每个点击都需要存储,并可通过某些界面进行浏览。以下是我对设计数据库表的看法。
PLAYER
- PlayerID
- Name
- ...
GAME
- GameId
- PlayDate
- ...
GAME-PLAYER
- GameId
- PlayerId
TAPS
- GameId
- PlayerId
- TapTime
- ...
所以你现在可能已经找到了问题 每场比赛12名球员x 800次点击=每场比赛“点击”表中的10,000行。
如果这项运动得以实现,水龙头数据库将变得非常庞大。是否有一些奇怪的db设计技巧可以用来阻止它成为一个问题?
答案 0 :(得分:1)
您可以根据游戏(比如游戏ID)对数据进行分片。您可以在运行时为新游戏创建Taps表,并将其命名为gameid_taps。
这样,你就不会有一个巨大的大桌子,你的查询会更好。