データベースを作成しています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ですか？
更新。ありがとうございます。別のテーブルを追加します。
あなたが解決しようとしている問題を私たちに伝えていないので、あなたの質問に答えるのは難しい.
現在の設計の問題点の 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 列に紛れ込むと、愚かで見つけにくいバグにつながる可能性があります。
別のテーブル「notification_settings」などを作成できます（おそらく作成する必要があります）。
ID
USER_ID
TYPE
VALUE
これにより、データベース テーブルをいじることなく、通知設定を簡単に追加できます。あなたが提案したように「厳密な」構造を持つことは、最終的に邪魔になり、拡張するのが難しくなることがあります。
ソーシャル リンクについても、同じことを行う必要があります。「user_social_accounts」という名前の別のテーブル
ID
USER_ID
NETWORK_ID