スレッド化されたコンバートを格納する最適化された方法は？ MESSAGE_ID、SENDER_ID（USER_ID）、タイムスタンプ、REFERENCE_ID -

Question

は、我々は以下の表（および列）

1. messages_tableを使用している...アーキテクチャは、（多くの1つ）の会話を保存する

   を設計することです

2. 受信者 - MESSAGE_ID、recipient_id（USER_ID）
3. unread_status_table - MESSAGE_IDは、我々はstoriある

をUSER_IDメッセージテーブルのメッセージを参照し、reference_idは開始スレッドのメッセージIDを格納します。

未読ステータステーブルは、未読のメッセージのみを保存します。

未読メッセージに別のテーブルを使用する必要があるかどうかはわかりませんが、すべてのメッセージが読み取られた場合はテーブルが空です。

助けてください。

Answer 1

このような質問には1つの答えがあるとは思いません。すべてのユーザー、会話の数、ハードウェア、システムがユーザーにどの程度反応するかなどの要件に依存します。未読メッセージに対して2番目のテーブルを持たないことで適切なパフォーマンスを得ることができれば、それはおそらくより良いルートです。可能な限り常に簡素化する。

私の考えでは、2番目のテーブルがあると、未読のメッセージではない可能性があります。代わりに、非常に並行性の高い状況では、そのテーブルにはプライマリキーとは別のインデックスはなく、新しいメッセージがプライマリキーにプッシュされます。多くの新しいメッセージが入ってきても、非常に高速な操作が可能になります。次に、ジョブを定期的に実行して少数のレコードを読み込んでメインテーブルにプッシュし、処理が遅くなってから2番目のレコードから削除します表。つまり、ユーザーは新しいメッセージを作成し続け、システムは応答し続けることができますが、受信者がメッセージを表示するまで少し時間がかかることがあります。

しかし、このアプローチは、パフォーマンスが必要とすることがわかっている場合にのみ必要です。