用户与日历关系及表规范化咨询：是否需拆分第三表？

当前设计的问题（违反规范化） #

当前的Calendar表设计存在明显的规范化缺陷，核心问题如下：

• 无法支持多参与者场景：一个日历事件通常会有多个参与者，但Attendee字段仅能存储单个用户ID，要么被迫重复创建多条内容几乎一致的Calendar记录（仅Attendee字段不同），要么无法完整记录所有参与者信息。
• 数据冗余严重：重复存储description、start_date等日历核心信息，既浪费存储空间，又极易引发数据不一致——比如修改事件描述时，所有重复的记录都需要同步更新，漏改就会出现数据矛盾。
• 引发数据操作异常：
  • 插入异常：若事件暂未确定参与者，Attendee字段需留空（违反非空约束）；若要添加多个参与者，无法在单条记录内实现。
  • 更新异常：修改事件信息时，需更新所有关联的重复记录，操作成本高且容易出错。
  • 删除异常：删除某个参与者的记录时，可能误删整个事件的核心信息。

优化方案：拆分出第三张关联表 #

必须通过新增关联表来实现用户与日历事件的多对多关系，具体设计如下：

1. User表（保持原有结构）：

   Id (主键), name, ...
   

2. Calendar表（仅保留创建者关联）：

   Id (主键), description, start_date, ..., CreatedBy (外键关联User.Id)
   

   注：CreatedBy是事件的创建者，一个事件仅对应一个创建者，因此直接存储在Calendar表符合规范。
3. CalendarAttendee关联表（实现多对多关系）：

   CalendarId (外键关联Calendar.Id), AttendeeId (外键关联User.Id)
   

   可将CalendarId和AttendeeId设为联合主键，避免同一用户重复加入同一事件；也可新增自增主键，具体视业务需求而定。

优化后的优势 #

• 消除数据冗余：日历事件的核心信息仅存储一次，参与者关系通过关联表记录，存储空间利用率更高。
• 避免操作异常：修改事件信息只需更新单条Calendar记录；添加/移除参与者仅需操作CalendarAttendee表，不会影响事件本身的核心数据。
• 符合第三范式（3NF）：所有字段均直接依赖于主键，无传递依赖或重复组，数据结构更稳定、易维护。

内容的提问来源于stack exchange，提问作者Jes