音乐平台数据库ER图：实体关联与空值问题解决方案咨询

问题1：评论关联歌曲/专辑的空属性处理 #

给你两个实用方案：

• 方案A：类型标记+单一目标ID
  在REVIEWS表里加一个review_type字段（设为枚举类型，取值*'song'或'album'*），再加一个target_id字段。然后通过数据库的检查约束或触发器做限制：当review_type是'song'时，target_id必须匹配SONGS表的主键；是'album'时必须匹配ALBUMS表的主键。这种方式不会出现空属性，逻辑紧凑，适合大多数场景。
• 方案B：拆分评论表
  直接拆成SONG_REVIEWS和ALBUM_REVIEWS两张表，各自关联USERS和对应的SONGS/ALBUMS。如果歌曲和专辑的评论规则（比如字段、审核流程）差异大，这个方案更清晰，不用额外做类型判断。

问题2：歌曲可选关联专辑的处理 #

这个逻辑很容易实现：直接在SONGS表加一个可选的album_id外键：

• 歌曲属于专辑时，album_id填写对应ALBUMS表的主键
• 独立存在的歌曲，album_id设为NULL
  关系型数据库允许外键为空，完全符合设计规范，能精准表达“可选归属”的业务逻辑，比复杂的子类型设计更简单直接。

关于RECORDINGS子类型的顾虑 #

你考虑的子类型设计其实是合规的，但没必要过度复杂化：

• 如果SONGS和ALBUMS有大量共同属性（比如发布日期、版权信息），可以抽象出RECORDINGS父实体，让两者作为子实体继承父属性，同时SONGS依然可以通过album_id关联ALBUMS——子实体之间的关联完全符合ER图设计规范，不存在冲突问题。
• 但如果两者的共同属性极少，直接用独立实体+可选外键的方案更高效，后续维护成本也更低。

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