1から多くの通知システム

Question

ほとんどの場合、データベース側で正しい方向へのプッシュを探していますが、1対多の通知システムに関して、あらゆるタイプのプッシュが受け入れられます（コードは賢明です）。

ユーザの集まりは、ユーザ関心（例えば、別のユーザ）によってトリガされる通知を受信する。

例

• USER1、USER2、およびUSER3サブジェクトA.
• 件名Aに関心のある、活性を掲示。
• user1、user2およびuser3はSubject Aからの通知を受け取ります。
• user2およびuser3は更新を表示しました。したがって、その更新で通知されなくなります。
• まだ更新を表示していないため、user1に通知されます。

マジック： 千人のユーザーは、同じ通知を受信し続けることができますが、個々のユーザーは、彼らが見た場合の通知の受信を停止または更新と対話します。

私の実装では、

は私が

id | sender | context | action | receiver | unread 
1 | Nobel | Prize | Won | Moi  | true #default 

ように私のDBに通知表を構築する際に対象トリガー通知私は、被験者Aに興味を持ってすべてのユーザーが、その後にその同じ通知を追加取得テーブルが異なるレシーバーと。

ユーザーが更新プログラムとやり取りすると、「未読列」がfalseに更新されます。 特定のユーザが歩いているとき（現実的ではない）、ユーザ名を持つ通知テーブルから通知を選択すると、未読の偽の数をカウントし、赤い通知バブルに番号を表示します。

私の意見

これは本当に冗長ようだ、とテーブルにも非常に迅速にまだmegaZillionのような名前を持っていない番号に成長することができます。件名に10,000の興味があるように、件名が冷蔵庫（実際のつぶやき）にソーダを見つけなかったために10,000の新しいレコードがテーブルに追加されます。

質問： これを行うには良い方法があります。

Answer 1

通知を一度だけ保存し、読み取り/未読フラグを別にnotificationID, userIDペアとして保存することもできます。 「読み込み」は、非アクティブなユーザーと対処するので、より安全な賭けに見えます。

次に、読んでいるフラグがないユーザーが興味を持っているすべての通知を照会します。

各ユーザーごとにこのすべてを追跡する必要がある場合は、とにかく多くのデータが必要になります。これは、常に各通知にユーザーの関係を保存する必要があることを意味します。ほとんどの場合、テーブルを正規化することができます。