我正在创建一个数据库users
。我想让用户选择他们想要通过电子邮件接收的通知。
现在我在表 users
(布尔类型)中有下几列:
-
notification_comment_photo
. -
notification_comment_comment
. -
notification_vote_photo
. -
notification_vote_comment
. -
notification_pm
. -
notification_followed
. -
notification_news
.
您怎么看,考虑到该表与表users
具有一对一的关系,我是否应该规范化表用户并创建另一个表notifications
?
我在社交链接(Twitter,Facebook,google+等)方面也有同样的问题。links
单独制作表格更好吗?
上。谢谢大家,我将添加单独的表。
很难回答你的问题,因为你没有告诉我们你想解决什么问题。
当前设计的一个问题是,它需要对要存储的每种新通知类型进行架构更改 - 如果要在用户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,并决定将用户链接到通知类型的任何记录都意味着他们已订阅。
此设计允许你添加新的订阅类型,而无需更改架构。我相信它与@Daniel建议的设计相似,但他不包括notification_type表,而是依赖于名称-值对。我不喜欢这个 - 当拼写错误滑入 TYPE 列时,它可能会导致愚蠢、难以找到的错误。
你可以(并且可能应该)创建一个单独的表"notification_settings"或其他东西。
ID
USER_ID
TYPE
VALUE
这使您可以轻松添加通知设置,而不会弄乱数据库表。正如您所建议的那样,拥有一个"严格"的结构有时会最终成为障碍,并且更难扩展。
对于您的社交链接,您也应该这样做。另一个名为"user_social_accounts"的表
ID
USER_ID
NETWORK_ID