動的通知システム - これは私以外の誰にとっても奇妙に見えますか？

Question

私は、私のソリューションがデータベース設計の何らかの根本的なルールを破っているかもしれないと懸念していますが、私はかなり動的だと思う通知システム用の構造を持っています。私は疑問

通知

id 
notification_type_id 
data 
created_at 

ユーザー通知

user_id 
notification_id 
is_read 

部分はJSON形式で（関連データを保持することである、通知表のデータ列であります）を使用してメッセージを作成します。たとえば、通知が投稿に追加された新しいコメントに関するものである場合、データには、投稿のIDと、投稿にコメントして必要なメッセージを作成するユーザーのIDが含まれます。

例：{post_id: 123, user_id: 456}は、「ダンボがあなたの質問に答えましたか？」というメッセージを作成します。

他のレコードへの複数の参照を保持するという考えは私には間違っていますが、かなり動的な選択肢のようです。私が考えることができる唯一の他の選択肢は、それ以前にメッセージを生成してそれをデータベースに格納することです。これは関係するすべての人が同じ正確なメッセージを受け取るので静的すぎます。

Answer 1

リレーショナルモデルでは、任意の複雑な型を許可します。複合タイプは、いくつかの内部構造を持っている場合は、次に

• DBMSはそれを無視し、または
• DBMS（ユーザ）は、それを操作するための機能を提供します。

日付は、例えば内部構造を持っています。データベース管理システムは、その構造体を切り詰め、その一部を抽出し、間隔を加算したり減算したりすることによって、その構造体を操作する関数を提供します。

JSONにも内部構造があります。 DBMSがJSONデータ型をサポートしている場合、それを操作する関数が提供されます。そうでない場合は、JSON型であることを無視し、保存されたJSONデータをユーザーに返します。

これまでのところ問題ありません。

しかし、そう言っています。 。 。

例：{post_idの：123、USER_ID：456} "？ダンボ はどのくらいそれが費用がかかり、あなたの質問に答え..." というメッセージを建設します

dbmsはuser_id 456が存在することを保証できないため、呼び出し側はID番号から名前への変換が機能するかどうかを知ることができません。投稿ID 123がまだ存在するかどうかもわかりません。この種の制約は外部キーのためのものであり、JSONとして格納されたID番号に外部キー制約を適用することはできません。

あなたの主なリスクは、ナンセンス（またはNULL）を呼び出し元に返すことです。場合によっては、それは完全に防御的です。 （ブログなど、しばらくの間ナンセンスメッセージが出たら気になる人は？）他のケースでは、致命的なものかもしれません。

「ダンボーさんがあなたの質問に「どれくらい...」答えたというテキストを保存した場合、削除されたユーザーや投稿のために失敗することはありません。投稿とユーザーの両方が削除されても、「ダンボーはあなたの質問に答えました、「どれくらい...」というメッセージは、依然として真の事実です。 （あなたのシステムが削除をどのように処理するかに応じて、やや役に立たないかもしれませんが）

Answer 2

正規化されたデータベースが必要な場合は奇妙に思えます。エンティティAがエンティティからの依存関係を持つ場合Bがある場合Aに外部キーを入れます。いくつかの依存関係 - 同じ数のキー。

Notificationsエンティティの別の構造体の問題が、notification_typeに応じて表示されます。つまり、データベースにはの継承があります。ニーズに合った適切なアーキテクチャを作成するための戦略がいくつかあります。比較のためにthisを試してください。

私は問題を正しく理解しました。