Facebookのためのデータベースデザイン、アプリケーションのように

Question

内部アプリケーションのためのアプリケーションのようなfacebookメッセージを設計する。

これはどのように設計するのですか？このデザインを改善する方法はありますか？感謝:)

MESSAGE 
Id 
Subject 
Content 
ReadDate -- datetime 
DeletedDate -- datetime 
CreatedBy -- userid 
CreatedOn -- datetime 

MESSAGE_COMMENT 
Id 
MessageId 
Content 
CreatedBy -- userid 
CreatedOn -- datetime 

MESSAGE_RECIPIENT 
Id 
MessageId 
Recipient -- UserId 
ReadDate -- datetime 
DeletedDate -- datetime 

EDIT：そこデザインで不足している何かであるかもしれないか、それが間違っている可能性があり、私に知らせてください。

Answer 1

まず、過すべての設計の観点から、いくつかのマイナーな提案...あなたがやりたいものに依存：あなたは、フィールド名のパスカルケースを使用しているので、

1. テーブル名に一貫性を持たせるためにもそれを使用する必要があります。したがって、MESSAGE_COMMENTはMessageCommentでなければなりません。

2. フィールド名 "Id"は、各テーブルで異なるものを使用するため、再使用しないでください。したがって、メッセージの "Id"は "MessageId"、MessageCommentの "Id"はMessageCommentIdでなければなりません。

3. フィールドが外部キーの場合は、それが指すフィールドの名前を含む必要があります。したがって、「CreatedBy」は「CreatedByUserId」で、「Recipient」は「RecipientUserId」でなければなりません。あなたのフィールドに名前を付ける方が明白になればなるほど、追加のコメントやドキュメントが少なくて済むので、他の人が何を意図しているのか分かりにくくなることはありません。

さて、限り「これはXを行うための適切な設計である」の質問に関しては、あなたは、このシステムの作業を想像する方法の詳細を与える必要があります。メッセージは親であるのに対して、それに対する応答はすべてMessageCommentsと見なされます。これまでのところはOKです。

MessageRecipientのより正確なレベルにも存在するメインメッセージテーブルで「ReadDate」が必要な理由がわかりません。当然のことながら、最初に読み取られた時間をトラップしたいのでない限り、特定のMessageのすべての受信者を調べることによってMessageRecipientテーブルから取得することもできます。

最後に、「MessageRecipientId」を持っていなくても、「MessageId」と「RecipientUserId」を複合プライマリキーとして使用することを検討する必要があります。これにより、メッセージにRecipientUserIdを1回だけ追加することができます。これらの2つのフィールドに固有の索引を追加する必要はありません。

Answer 2

私は、これはかなりエログで、メッセージを送受信すると思います。
より