Question

我认为有必要对用户通知的数据库进行去规范化。例如，在标记帖子（应由用户考虑）时，我们会添加一列flag ENUM('yes', 'no')（或状态列）。查找用户的标记事件可以通过使用user_id='XX' AND flag='yes'的WHERE子句进行计数。

这种标准化结构很好;但是如果我们有不同类型的通知呢？例如帖子，评论，照片的标志......这意味着当用户访问他的个人资料页面时，我们需要计算几个表格。这对于像stackexchange这样的跨项目更为严重，因为我们会收到不同站点的通知。

我认为反规范化有助于将通知列添加到用户表中

post_flags tinyint(3),
comment_flags tinyint(3),
photo_flags tinyint(3),

在这种情况下，我们需要运行一个额外的写查询来更新每个相应操作的用户标志列。例如，标记帖子时：UPDATE users SET post_flags=post_flags+1 WHERE user_id='XX'。我关心的是确保执行后一种查询，以避免这个数字与被标记的帖子数量之间的任何不匹配;但我认为它可以通过TRANSACTION保护。

通过这种方式，我们可以通过一个查询获取所有频繁访问的个人资料页面的通知。

我是否在正确的轨道上？或其他棘手的方法是否常见？

Answer 1

这是否正常化？看起来创建这三列是一种更好的组织方式，对我来说似乎更正常吗？

Answer 2

使用用户通知表可能会更好。

create table user_notifications (
  user_id integer primary key, -- ? references users, not shown
  post_flags unsigned tinyint(3) not null default 0,
  comment_flags unsigned tinyint(3) not null default 0,
  photo_flags unsigned tinyint(3) not null default 0
);

一个单独的，更窄的表是合乎逻辑的，并且（可能）更快。对于标志没有签名，因为没有任何意义的负数，并且MySQL不强制执行CHECK约束。

就规范化而言，user_notifications为5NF。

Answer 3

我认为这不是很有效。当你需要找到标志的组合时，它可能很有用，例如post_flags或comment_flags或photo_flags，查询的顺序也很重要。

如何对用户通知的mysql数据库进行去规范化？

3 个答案: