数据库2NF转3NF主键、外键及复合主键使用相关问题咨询

问题1：外键是否可以作为复合主键的组成部分？ #

完全合规。外键的核心作用是关联其他表的主键、保证参照完整性，没有任何数据库规范禁止外键作为当前表复合主键的组成部分。
你提到的member_number+email_nr作为复合主键的场景非常典型：member_number作为关联用户表的外键，和邮箱序号组合后，恰好能实现「同一用户下的邮箱编号唯一、不同用户下的邮箱编号可重复」的需求，完全符合关系型数据库的设计逻辑。

问题2：是否支持基于复合主键的某一列自动递增另一列的数值？ #

原生SQL标准没有直接提供这种「分组自增」的通用语法，但主流数据库都有对应的实现方案：

• MySQL：建表时指定复合主键为(member_number, email_nr)，同时将email_nr设为AUTO_INCREMENT，MyISAM和InnoDB引擎原生支持这种分组自增逻辑，新增同member_number的记录时会自动给email_nr递增加1。
• PostgreSQL：可通过序列+触发器、生成列实现，也可以在INSERT语句中通过子查询COALESCE(MAX(email_nr), 0) + 1计算得到对应序号。
• SQL Server：可通过SEQUENCE对象配合分区实现，或者同样用INSERT时的子查询计算序号。
  注意高并发插入场景下需要配合事务或者行锁避免生成重复值。

问题3：现有设计还有哪些不符合规范的问题？ #

仅从你描述的场景，给出几个通用的3NF合规检查点：

• 检查是否存在部分依赖：所有非主键字段必须完全依赖整个复合主键，不能只依赖其中某一列。比如如果邮箱表中存储了用户昵称，而用户昵称只依赖member_number、和email_nr无关，就违反3NF，需要将这类字段拆分到用户主表。
• 检查是否存在传递依赖：非主键字段必须直接依赖主键，不能依赖其他非主键字段。比如如果表中存储了邮箱域名后缀，而域名后缀可以通过邮箱地址字段推导出来，就属于传递依赖，要么拆分到单独的域名表，要么直接不存储该字段、查询时实时计算即可。
• 检查是否存在冗余字段：如果有可以通过其他字段计算得到的字段，比如同时存储了用户出生日期和年龄，就属于冗余，违反3NF，建议只保留不可推导的原始字段。
• 检查是否存在多值字段：单个字段如果存储了多个用分隔符拼接的值，比如单个字段存了多个用户标签，就违反1NF，需要拆分出单独的关联表。

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