我想提高通知板的速度。它从event表中检索数据。
此时events MySQL表看起来像这样
id | event_type | who_added_id | date
在event表中，我存储了一行，其中包含有关特定事件的信息。每次用户A请求新通知时，查询都会在表中运行，并查看用户B添加的通知是否适合他（他们必须是朋友，同一组的成员，之前已经聊过）。
表events变得很大，因为页面加载的查询量很大。
我正在考虑完全改变这个设计，而不是添加一个事件行，然后比较用户的事件是否适合，添加与感兴趣的用户一样多的行。我会更改表events结构，如下所示：
id | event_type | who_added_id | forwho_id | date
现在，如果用户B创建了一个感兴趣其他50个成员的事件，我创建了50行具有相同信息的行，而在'forwho_id'字段中，我提到了必须获得此通知的50个成员。
我认为查询将变得更加简单，搜索它将花费更少的时间。
你怎么想：
1.这是存储此类数据的好方法还是我们应该不惜一切代价避免重复数据？
2.如果感兴趣的用户数量不是50而是数百，那么您认为events表的表现如何？
感谢您阅读本文，我希望自己能够理解。
答案 0 :(得分：0)
重复数据并非“糟糕”，并且不应“不惜一切代价”。
什么是“坏”是不受控制的冗余，以及当逻辑数据模型不是第三范式时出现的问题。可以接受并期望实现将偏离逻辑数据模型，并为性能引入冗余。
您的修改后的设计看起来适合您的需求。