Проектирование базы данных, чтобы не было огромной таблицы

Question

Проект, который я разрабатываю, предназначен для компании, в которой я работаю, поэтому мне пришлось подумать о похожем сценарии, который потенциально мог бы иметь примерно ту же проблему (если она вообще возникла).

Право, давайте изобретать новый вид спорта. «Постукивание последовательности». До 12 человек могут играть одновременно. Таймер запускается и длится 2 часа. Перед игроками стоит цифровая клавиатура, они должны нажать ее через 10 секунд после запуска таймера, а затем каждые десять секунд, пока таймер не достигнет двухчасовой отметки.

Приложение, которое мне нужно разработать, - это запись статистики этого довольно скучного вида спорта. Каждое нажатие должно быть сохранено и доступно для просмотра через некоторый интерфейс. Вот как я думал о разработке таблиц базы данных.

PLAYER
 - PlayerID
 - Name
 - ...

GAME
 - GameId
 - PlayDate
- ...

GAME-PLAYER
 - GameId
 - PlayerId

TAPS
 - GameId
 - PlayerId
 - TapTime
 - ...

Итак, вы, наверное, уже разобрались в проблеме.
12 игроков х 800 фишек за игру = 10 000 фишек в таблице «фишек» за игру.

Если этот вид спорта заинтересует, база данных метчиков станет огромной. Есть ли какая-нибудь хитрая хитрость в разработке БД, которую я мог бы использовать, чтобы это не стало проблемой?

Answer 1

Вы можете осквернить свои данные на основе игр (скажем, идентификатор игры).Вы можете создать таблицу Taps во время выполнения для новой игры и назвать ее как gameid_taps.

Таким образом, у вас не будет огромной большой таблицы, и ваши запросы будут работать намного лучше.