SQL Server - SQL - ユーザーごとの既読/未読通知のテーブル構造

Web アプリケーション上に通知モジュールを作成する必要があり、通知がまだ読まれていないことを示す赤いバッジを表示する必要がないように、どのユーザーが通知を読んだのかを知りたいと考えています。

私は 2 つの解決策を考えました。

最初のものは少し単純ですが、実装と保守は簡単だと思います。

解決策 #1:

CREATE TABLE [Notifications1] 
(
    Id integer NOT NULL,
    Title varchar(255) NOT NULL,
    Description varchar(255) NOT NULL,
    DateInserted datetime NOT NULL,
    ReadByUsers varchar(MAX) NOT NULL
)

この場合、ユーザーが未読通知を開いたときに、ReadByUsers 列にユーザー ID を追加し、10,12,15,20 ... のようになります。

ユーザーが通知を読んだかどうかを確認する必要がある場合は、単純に列をクエリしてユーザー ID が含まれているかどうかを確認します。

2 番目の解決策は、「ベスト プラクティス」アプローチのように見えますが、もう少し複雑になります。複雑で、もう少し重いと思います..

解決策 2:

CREATE TABLE [Notifications] 
(
    Id integer NOT NULL,
    Title varchar(255) NOT NULL,
    Description varchar(255) NOT NULL,
    DateInserted datetime  NOT NULL,

    CONSTRAINT [PK_NOTIFICATIONS] 
        PRIMARY KEY CLUSTERED
)

CREATE TABLE [Notification_Users] 
(
    NotificationId integer NOT NULL,
    UserId integer NOT NULL
)

この場合、通知を見たユーザーを、メイン テーブルの通知 ID の関係 (1 対多) を使用して別のテーブルに保存します。次に、Notification_Users テーブルをチェックして、ユーザーが通知を見たかどうかを確認できます。

次の点にも注意してください:

ユーザーが通知を見た時間を知る必要はありません。

このアプリケーションのユーザー数がすぐに 10,000 人を超えることはないと予想されます。

通知は数か月後にデータベースから削除されます。したがって、一度に最大 10 件の通知を送信できます。

より良い実装のための提案はありますか?

ありがとう

5

。 。リストを文字列に格納することは、SQL データベースを設計する上で間違った方法です。これであなたの質問の答えが得られるはずです。

2020 年 9 月 4 日 20:39

重いかどうかは考え方の問題です。オプション 2 のほうが簡単に見えますが、DB レベルでは挿入のみで、その後に存在するかどうかが決まります。また、2 つのフィールドに主クラスター化キーを使用すると、SQL エンジンにとってそれほど面倒ではなくなります。オプション 1 ではさらに多くのことが必要です読み取り時に不特定のクエリを実行する場合は、readbyusers 列を解析する必要があります。読み取りの方がより一般的な操作であることを考えると、これが最初に検討すべきユースケースです。

2020 年 9 月 4 日 20:46

バイナリ?いいえ。これは、通知の PK と同じデータ型 (できれば同じ名前) である必要があり、適切な外部キー (複数のキーもあり、UserID は何らかのユーザー テーブルに対する FK ではありませんか?) とともに必要です。また、(データ型をサポートするものに対して) 長さを指定せずにデータ型を定義する習慣を身につけないでください。 binary は binary(1) とまったく同じです

2020 年 9 月 4 日 20:51

DateInserted は、必要な精度の datetime または datetime2 である必要があります。 Time データ型は 255 桁の小数部をサポートしておらず、日付コンポーネントもありません。

2020 年 9 月 4 日 20:54

Notification_User_Events という 3 番目のテーブルを作成し、それに行を追加するときに、Notification_Users テーブルのビット列を更新することもできます。o メッセージが読まれたことを示します

2020 年 9 月 4 日 21:52

解決策 #2 が推奨される解決策です。

ID のリストを保存することは、正規化されたソリューションではありません。私の意見では、これを 2 つのテーブルに分割することによる投資収益率は、知覚される複雑さを軽減します。

以下に有益な情報をいくつか紹介します。正直に言うと、ネット上にあります。

「最高」のデータベース練習

https://softwareengineering.stackexchange.com/questions/358913/is-storing-a-list-of-strings-in-single-database-field-a-bad-idea-why