Проблема схемы базы данных в отношении реализации таблицы

Question

Я создаю приложение, которое требует, чтобы пользователи ежедневно заполняли анкету. Вопросы всегда одинаковы. По сути, это дневниковая система, и «записи» делаются ежедневно (каждая запись представляет собой набор ответов на 5 вопросов определенной даты конкретным пользователем).

Мой вопрос такой:

Каков наилучший способ согласовать это с точки зрения схем баз данных? Я думал о двух столах:

Users:
username(pk)
password
.
.
diaryNo

Entries:
date(pk)
diaryNo(pk)
Qu1
Qu2
...

Моя проблема в том, что в таблице записей будут храниться записи для всех пользователей. Отдельная запись может быть отображена для пользователя с помощью ссылки diaryNo. Очевидно, что через некоторое время таблица записей станет массивной, а производительность sql снизится.

Это должно быть распространенной проблемой - есть ли обходные пути? лучшие идеи для реализации?

Answer 1

Прежде всего - PK НЕ должен иметь никакого делового значения - представьте, что если пользователь попросит изменить логин. Просто используйте простой autoinc. Вы должны использовать эти таблицы:

Users (id(PK), username, ....)
Questions (id(PK), question, ....)
Answers (id(PK), userId(FK)(I), questionId(FK)(I), date(I), answer)

Answer 2

Индекс на Entries (diaryNo) или Entries (diaryNo,date), особенно если вы часто выбираете Entries на основе diaryNo. то есть diaryNo=? появляется в большинстве запросов select.