3

通知システムを実装したい。ユーザーがいて、各ユーザーには通知設定があります

構造 1:

 Users                Notification_settings                Notifications
 -id (pk)             -id                                   -id (pk)
 -username            -user_id (fk) references Users        -user_id (fk)
 -password            -receive_email (boolean)              -message
                                                            -is_read

構造 2:

 Users                                               Notifications_settings
 -id (pk)                                             -id (pk) 
 -setting_id (fk) references Notifications_settings   -receive_email
 -username                                            
 -password            

 Notifications
 -id (pk)
 -user_id (fk)
 -message
 -is_read

通知システム用にどのデータベース構造を選択するか、またはその他のデータベース構造を選択しますか?

4

3 に答える 3

2

It seems like it should be users < notifications (one to many), but maybe you have a specific reason that it should be 1-1. In that case, I would make the parent table (the one without the FK column) the table with more one-to-many relationships. So, naturally, it would make sense to use store the user ID in the notification table.

It would seem that a notification would always have a user, but NOT vice-versa. Therefore, you should store the foreign key to a UserID in your notification table -- and not the other way around.

edit-- as others have suggested, if you truly do want a 1-1 relationship, you could just add notification fields to the User table. These seems to violate normalization rules at a glance, but if it reeeaaaally is a 1-1 relationship, then by all means, have at it

Edit 2- Since you explicitly stated that a notification does not exist without a user, I will definitively say that you should store the foreign key to a User in the Notifications table, no exceptions (except if you want to store notification information inside the user's table :)

Edit #2937:

You should store the user's notification preferences in the User table - there's no need to split that into a different table unless you have some obfuscated design and have 256 columns for your user already and that is the limit.

You should store the notifications in a separate table, with a One-Many Relationship from Users to Notifications. That is my final answe, Regis :)

于 2013-02-05T02:15:06.550 に答える
2

そして今、ジョー・セルコの引用のために:

強い実体とは、それ自体のメリットで存在する実体です。弱いエンティティとは、強いエンティティがあるために存在するエンティティです。典型的な例は、販売注文です。注文ヘッダーは強力で、注文の詳細は弱いです。注文がキャンセルされた場合、すべての注文の詳細が表示されなくなります。

それでは、ユーザーは通知なしで単独で存在できますか? 次に、Notifications テーブルには、Users への外部キーが必要です。逆は真ですか？それなら逆にしてください。これらはどちらも真実ではありませんか？次に、モデルが正しくない可能性があり、それらの間にジャンクション テーブルが存在する必要があります (一意の制約があっても) か、本当に同じテーブルに属している可能性があります。私は、これらを同じ表に入れるというこの最後のオプションは特に好きではありません。なぜなら、あなたはすでに、別個のエンティティーを説明する 2 つの名詞を自然に思いついているからです。

ユーザー以外の他のエンティティは通知を「持つ」ことができますか? この種の考え方は、このドメインをモデル化するのに役立つかもしれません。

更新- いくつかの追加のアイデア:

これらの列をすべて 1 つのテーブルに入れるとしたら、冗長なデータが含まれているように見えるのはどれですか? 今、いくつかの異なるメッセージしかないと想像してみましょう。おそらく、Notifications テーブルではなく Messages テーブルが必要であり、それと、Users に送信されたメッセージ (既読か未読かを含む) を保存できる User との間のジャンクション テーブルが必要です。この時点では receive_email の方がユーザーの属性として適している可能性がありますが、メッセージをユーザーにマップするだけで、このユーザーが電子メールを受信する必要があると言えます。これらは私が考えていることのほんの一部であり、アプリの理解を深めることにつながることを願っています.

また、bit/boolean データ型は ANSI SQL ではないことに注意してください。多くの場合、他のデータから派生する可能性があり、複数のステータスへのロード マッピングで int に変わる可能性さえあります。

于 2013-02-05T02:18:10.483 に答える
0

サイトのトラフィックがそれほど多くない場合は、すべてを同じテーブル (ユーザーと設定) に入れます。 これは、OPに関連する回答です。
通常、いくつかの条件が (一緒に) 発生した場合、1:1 を異なるテーブルに分けます。

  1. フィールドの各グループは、アプリ内の異なるモジュールに関連しています
  2. フィールドの各グループは、異なるレートでアクセスされます (たとえば、ログインごとのユーザー名/パスワード、週に 1 回または 2 回の課金設定)。
  3. サイトには膨大なトラフィックがあり、システムから少しでもパフォーマンスを引き出す必要があります

上からわかるように、ほとんどは分離する必要はありません。

于 2013-02-05T02:12:44.357 に答える