我的数据库表ABC的Schema设计存在哪些缺陷？

Hey，咱们来拆解一下你这个单表设计里的问题，都是实际开发和维护中容易踩的硬坑：

• 严重违反数据库规范化规则，冗余数据爆炸
  这个表把医生、患者、预约三个完全独立的实体信息揉在了一起。举个例子：同一个医生可能给N个患者预约，每次都要重复存储doc-name、doc-gender、qualification这些信息；同一个患者多次预约的话，pat-name、pat-gender、address这类固定信息也会反复存。这不仅浪费存储空间，更要命的是数据一致性没法保证——比如医生改名了，你得把所有他相关的预约记录全改一遍，漏改一条就会出现数据矛盾。

• 数据完整性与唯一性无法有效保障

  1. 没有主键：你没法唯一标识某一条预约记录，比如同一个患者同一天同一时间的同类型预约，完全没法区分，后续做更新、删除操作很容易误改数据。
  2. 缺乏约束：比如医生的资质qualification没法通过外键或枚举来限定合法值，很容易输入错误；患者的phone-num也没法统一校验格式，脏数据会越来越多。

• 扩展性和可维护性极差
  要是以后业务需求变了——比如要给医生加「科室」「职称」字段，给患者加「医保号」「紧急联系人」，你只能直接修改这个大表的结构，会影响现有业务的运行；而且要做一些统计（比如统计某个医生每月的预约量、某个患者的就诊历史），SQL查询会写得无比繁琐，性能也会随着数据量变大急剧下降。

• 字段命名不规范，语义模糊

  • registration _num里有个多余的空格，这在大多数数据库里都是不合法的字段名，会直接导致SQL执行报错。
  • registration_num没明确是「医生注册号」还是「患者注册号」，很容易被误解；type字段也没说明是「预约类型」「就诊类型」还是其他，语义完全模糊，后续维护的人根本不知道这个字段存的是什么。

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