3

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

这种归一化的结构很好；但是如果我们有不同类型的通知呢？例如，帖子、评论、照片的标志……这意味着当用户刚刚访问他的个人资料页面时，我们需要计算几个表。这对于像 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.

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

我在正确的轨道上吗？还是为此目的常见的另一种棘手的方法？

4

3 回答 3

1

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

于 2012-02-28T13:30:13.307 回答
1

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

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
);

一个单独的、更窄的表既合乎逻辑又（可能）更快。Unsigned for flags，因为负数没有意义，而且 MySQL 不强制 CHECK 约束。

就规范化而言，user_notifications 在 5NF 中。

于 2012-03-04T15:03:14.240 回答
0

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

于 2012-02-28T13:34:19.597 回答