通知システムについて

私はSEに通知システムを構築する方法を検討して、他の場所と私はここに受け入れ答えである液に描か発見されている：/programming/9735578/building-a-notification-system た用途この構造：

╔═════════════╗      ╔═══════════════════╗      ╔════════════════════╗
║notification ║      ║notification_object║      ║notification_change ║
╟─────────────╢      ╟───────────────────╢      ╟────────────────────╢
║ID           ║—1:n—→║ID                 ║—1:n—→║ID                  ║
║userID       ║      ║notificationID     ║      ║notificationObjectID║
╚═════════════╝      ║object             ║      ║verb                ║
                     ╚═══════════════════╝      ║actor               ║
                                                ╚════════════════════╝

通知は、何か（オブジェクト=イベント、友情..）が誰か（俳優）によって変更（動詞=追加、要求）され、ユーザー（対象）に報告されることに関するものです。これが正規化されたデータ構造です（MongoDBを使用しましたが）。特定のユーザーに変更を通知する必要があります。つまり、ユーザーごとの通知です。つまり、100人のユーザーが関与している場合は、100の通知を生成します。

最初はこのアプローチを理解していると思っていましたが、それを実装する準備を始めたとき、私は明らかにそれを特によく理解していないことに気付きました。回答に関する最後のいくつかのコメントは、ソリューションの理解に苦労した他のユーザーからの質問です。

私がいないことを確認これは私が次のように終わるだろうモデルがある場合だけど、それが持っているupvotesの数を考えると、私はそれは私がする恩恵を受けるだろうと確信して理解し、それを、私は確かのようにもっと勉強したいです。これがこの解決策を把握するのに苦労した他の人にも役立つことを願っています（偶然、私はこの質問に向けてその答えにコメントを残すのに十分なインターネットポイントを持っていません、他の誰もしてください！）

ご質問

正しく理解できれば、notificationObjectIDはnotification_objectテーブルを指す外部キーであり、notificationIDは通知テーブルを指す外部キーです。オブジェクトは、通知の対象となるデータベースエントリ（特定のイベントや投稿など）のIDを参照する外部キーであるように見えますが、そのIDが属するテーブルを示す別のフィールドが必要ではないでしょうか？

著者が書いた

notification_object.objectは、文字列「friendship」のような変更タイプを識別します。私が話す追加データを含む変更されたオブジェクトへの実際の参照は、notification_change.notificationObjectIDにあります。

私には意味がないようです。オブジェクトは文字列（enum？）で、notificationObjectIDは通知の対象となるオブジェクトを参照する外部キーですか？それでは、真ん中のテーブルと正しいテーブルはどうやってつながっているのでしょうか？

中央のテーブルは、通知の対象となるオブジェクト（またはオブジェクトのタイプ）、たとえばイベントや投稿を指定しているようです。次に、同じオブジェクトタイプを指すnotification_changeのエントリを多数持つことができます。これにより、通知（「25人のユーザーがXの壁に投稿されました」など）をバンドルできます。

しかし、左テーブルと中央テーブルの間に1：nの関係があるのはなぜですか？「25人のユーザーがSamのウォールに投稿されました」と「Maryが彼女の「Friday Picnic」イベントを更新した同じ通知IDを提供しますか？同じユーザーのすべての通知に同じ通知IDがある場合、なぜ左？

パフォーマンスに関する質問-ジョンがメアリーのピクニックイベントにコメントを投稿するとします。notification_changeエントリを作成する前に、Mary's Picnicのnotification_objectが既に存在するかどうかを確認するためにルックアップを行う必要があるようです。これはパフォーマンスに悪影響を及ぼしますか、それとも問題ではありませんか？前の段落からの質問を続けると、どのように我々は知っているだろう通知指すようにエントリnotification_objectをしますか？

このような徹底的な質問に感謝し、混乱のすべてに申し訳ありません-最初の回答から1年後にコメントするのは難しく、今では3年後にコメントします。現在、バックエンドに通知を保存しており、実際に適用せずに適切な判断を下すかどうかわからない

執筆時点で私は思う：

• はい、いいえ、notificationIDは外部キーでしたが、notificationObjectIDは外部キーではありませんでした。テーブルを結合するには、別のFKフィールドが必要です。私はそれについてあまり明確ではないことに私のモンゴの経験を責めます:(
• はい、いいえ、notification_object.objectはあいまいです。文字列または複雑なもの（JSON、またはFK）として使用できるためです。私の場合、それはただの名詞でした。

そのため、すべては通知の外観に依存します。単純な場合、通知全体をフレンドページなどのURLにリンクするだけです。そのため、オブジェクト（entityType）を文字列として使用すると便利です。URLを結び付けます。

「3つの友達リクエストが追加されました」という通知は、別の方法で保存できます。

一度に1つずつ表示したい場合は、3つの通知、3つの通知オブジェクト（friend_request）、および特定の友人ユーザーにリンクするnotification_changeの3つのエントリがあります。

1つの通知を表示する場合-1つの通知、1つ以上のオブジェクト、3つ以上のアクションがあります。したがって、この複雑なケースでは、«ユーザーA、ユーザーB、ユーザーCから3つの友人リクエストがあります»-各ユーザーにnotificationObjectIDsを使用し、通知テキストにいくつかのリンクがあります。

1つまたは3つのfriend_requestオブジェクトを使用する必要がありますか？による

1. オブジェクトとアクションは何ですか。«記事がいいね/コメントされています» それとも、«like / comment added»で、オブジェクト階層は表示中にのみリンクされますか？意味的に非常に近いと思われる«ユーザーのコメント»と«写真のコメント»を区別するfacebookがあります。

2. 通知を削除できますか、または履歴が必要ですか？友人リクエストを送信してからキャンセルするか、コメントしてから記事を削除すると、何かと同じように、そして違って-この履歴を（別のアクションとして）エンドユーザーに2つの異なるアクションとして表示する必要がありますか？おそらくない。さらに、技術的に複雑です-既存のnotification_objectがある場合は検索する必要があり、新しいnotification_changeを追加する（そうでない場合-新しいオブジェクトを追加する）ので、後でnotification_changeを検索して削除する必要があります。代わりに、同じ通知に別のnotification_objectを追加し、カスケード削除されたアクションがなくなった場合は削除します。

一方、履歴から何も消去されないアクションをグループ化すると便利な場合があります。

執筆の時点で、左と中央のテーブル間の1：n関係が行われたのは、そのためだと思います。同じエンティティ（中央右のテーブル）のアクターだけでなく、いくつかのオブジェクト/エンティティによって通知をグループ化できます。

ただし、左中央の関係をn：1に戻すことで、ケース全体を簡素化し、ストレージを最適化できるため、1つのイベントに対してユーザーごとの通知を生成できます。

それがもっとこのように見えるように。

╔═════════════╗      ╔═══════════════════╗      ╔════════════════════╗
║notification ║      ║notification_object║      ║notification_change ║
╟─────────────╢      ╟───────────────────╢      ╟────────────────────╢
║ID           ║←—n:1—║ID                 ║—1:n—→║ID                  ║
║noteObjFK    ║      ║entityType         ║      ║noteObjFK           ║
║viewerUserID ║      ║entityID           ║      ║actionOnEntity      ║
╚═════════════╝      ╚═══════════════════╝      ║actorUserID         ║
                                                ╚════════════════════╝

これが役に立てば幸いです