The project I'm creating is perfect for the organization Sometimes for and so i have needed to think about an identical scenario that will potentially have roughly exactly the same problem (if it is an problem whatsoever).

Right allows invent a brand new sport. "Tapping consistency". As much as 12 people can enjoy at the same time. A timer begins and continues for just two hrs. The gamers possess a digital pad before them, they need to tap it ten seconds following the timer begins after which every 10-seconds before the timer reaches the 2 hour mark.

The applying I have to design here's to record the data of the rather dull sport. Each and every tap will have to be saved and become browseable via some interface. This is how I figured about creating the database tables.

PLAYER
 - PlayerID
 - Name
 - ...

GAME
 - GameId
 - PlayDate
- ...

GAME-PLAYER
 - GameId
 - PlayerId

TAPS
 - GameId
 - PlayerId
 - TapTime
 - ...

So you've most likely determined the issue right now.
12 gamers x 800ish taps per game = 10,000ish rows within the "taps" table per game.

If the sport catches on, the taps database will become enormous. Can there be some whizzy db design chicanery I possibly could use to preclude this from being a problem?

You are able to Shard your computer data according to games (say game id). You may create the Taps table in the runtime for any new game and title it like gameid_taps.

This way, you won't have a big large table as well as your queries works so much better.