2

データベースを作成していますusers。メールで受け取りたい通知をユーザーが選択できるようにしたいと考えています。

これで、テーブルに次の列ができましたusers(ブール型):

  • notification_comment_photo.

  • notification_comment_comment.

  • notification_vote_photo.

  • notification_vote_comment.

  • notification_pm.

  • notification_followed.

  • notification_news.

notificationsこのテーブルが table と 1 対 1 の関係を持つことを考えると、 table users を正規化して別の table を作成する必要があると思いますusersか?

また、ソーシャル リンク (twitter、facebook、google+ など) にも同じ問題があります。別のテーブルを作成した方が良いlinksですか?

更新。ありがとうございます。別のテーブルを追加します。

4

2 に答える 2

4

あなたが解決しようとしている問題を私たちに伝えていないので、あなたの質問に答えるのは難しい.

現在の設計の問題点の 1 つは、保存する新しいタイプの通知ごとにスキーマを変更する必要があることです。ユーザーが un_followed になったときに通知したい場合は、users テーブルに列を追加する必要があります。

次のようなスキーマを検討します。

TABLE: users
------------------
ID
...

TABLE: notification_types
----------------------
ID
Description

TABLE: user_notifcation_subscriptions
-----------------------------------------
user_id
notification_type_id
subscribed (bool)

user_notification_subscriptions から「subscribed」列を除外し、ユーザーを通知タイプにリンクするレコードは、ユーザーが購読したことを意味すると判断できます。

この設計により、スキーマを変更せずに新しいサブスクリプション タイプを追加できます。@Danielが提案するデザインに似ていると思いますが、彼はnotification_typeテーブルを含めず、代わりに名前と値のペアに依存しています。私はこれが好きではありません - タイプミスが TYPE 列に紛れ込むと、愚かで見つけにくいバグにつながる可能性があります。

于 2012-10-14T08:05:44.090 に答える
1

別のテーブル「notification_settings」などを作成できます(おそらく作成する必要があります)。

 ID
 USER_ID
 TYPE
 VALUE

これにより、データベース テーブルをいじることなく、通知設定を簡単に追加できます。あなたが提案したように「厳密な」構造を持つことは、最終的に邪魔になり、拡張するのが難しくなることがあります。

ソーシャル リンクについても、同じことを行う必要があります。「user_social_accounts」という名前の別のテーブル

ID
USER_ID
NETWORK_ID
于 2012-10-14T06:47:25.260 に答える