テーブル実装に関するデータベーススキーマの問題

Question

私は、ユーザーが毎日アンケートに記入する必要があるアプリを開発しています。質問は常に同じです。基本的には日記システムであり、「エントリ」は毎日作成されます（各エントリは、特定のユーザーが特定の日付に5つの質問に対する回答のセットです）。

私の質問はこれです：

データベース回路図の観点からこれをorgabiseするための最良の方法は何ですか？私は2つのテーブルを持つことを考えていた：

Users: 
username(pk) 
password 
. 
. 
diaryNo 

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

私の問題は、エントリテーブルはすべてのユーザーのエントリを格納するということです。 diaryNoをリンクすることによって、特定のエントリをユーザにマッピングすることができます。明らかにしばらくすると、エントリテーブルが大量になり、SQLパフォーマンスが低下します。

これは共通の問題である必要があります。回避策はありますか？実装のためのより良いアイデア？

Answer 1

Entries (diaryNo)またはEntries (diaryNo,date)のいずれかのインデックス。特にdiaryNoに基づいてEntriesを頻繁に選択している場合。すなわち、diaryNo=?がほとんどの選択クエリに現れます。

Answer 2

まず最初に、PKはビジネス上の意味を持つべきではありません。ユーザーが変更ログインを要求した場合はどうなるでしょうか？単純なautoincを使用してください。 これらの表を使用する必要があります。

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