该关系型数据库模式存在哪些问题？附诊所数据库设计需求

嘿，我来帮你拆解这个单关系模式ABC的问题——这种把所有数据塞进一张大表的设计，在诊所运营的场景里会踩很多实际的坑，咱们一条条说清楚：

1. 严重的数据冗余 #

• 医生的核心信息（doc-name, doc-gender, registration_num, qualification）会跟着每一条预约记录重复存储。比如同一个医生一天有8个患者预约，他的资质、执业注册号这些固定信息就会被存8遍，既浪费存储空间，还会让表的数据量快速膨胀，拖慢后续的查询速度。
• 患者的基础信息（pat-name, pat-gender, DOB, address, phone-num）也是同理，一个患者多次预约的话，这些信息会反复出现在表中，完全是不必要的重复。

2. 更新异常（Update Anomalies） #

如果某个医生的执业资格更新了，你得手动找到这个医生的所有预约记录去修改qualification字段——万一漏改了其中一条，就会出现同一个医生同时有两种不同资质的矛盾数据，后期做合规检查或者医生绩效统计时会出大问题。
同样，患者搬家更换地址后，你也得更新他所有预约记录里的address字段，漏改的话就会导致同一个患者有多个不同的地址信息，发通知邮件时很可能会寄错地方。

3. 插入异常（Insert Anomalies） #

• 假设你想录入一位刚入职的新医生，但他还没有任何患者预约，你根本没法把他的信息插入到ABC表里——因为表中包含患者和预约的必填字段（比如pat-name、预约时间等），没有这些值就无法完成插入，导致医生信息没法提前建档。
• 反过来，新患者还没预约就诊，你也没法单独存储他的地址、电话这些基础信息，必须等他完成预约才能录入，这显然不符合诊所提前为患者建立档案的实际需求。

4. 删除异常（Delete Anomalies） #

如果某个患者取消了所有预约并销户，你删除他的所有预约记录时，这个患者的地址、电话这些关键联系信息也会跟着被删掉，以后哪怕想联系他都找不到数据了。同理，如果删除某个医生的最后一条预约记录，这个医生的执业资质、注册号等核心信息也会直接丢失。

5. 无法灵活支撑业务需求 #

你的三个核心业务需求，用这个单表设计都会变得很棘手：

• 列出指定日期医生的预约信息：虽然能查，但因为冗余数据多，你需要额外过滤重复的医生信息，查询效率低且逻辑繁琐；
• 提供指定日期的可用时段：单表只能从已有的预约记录反推可用时间，逻辑非常复杂，而且如果医生有固定排班但还没被预约，这些时段信息在单表里根本不存在，没法准确返回可用时段；
• 查询患者地址发通知：单表里的地址和预约绑定，万一患者更新了地址但旧预约记录没同步修改，你查到的可能是旧地址，直接导致通知发送错误。

按照数据库设计的规范化原则，你应该把这个大表拆分成至少三个核心表：

• Doctors：存储医生的唯一信息（比如doc_id作为主键，搭配doc-name, doc-gender, registration_num, qualification）
• Patients：存储患者的唯一信息（比如pat_id作为主键，搭配pat-name, pat-gender, DOB, address, phone-num）
• Appointments：存储预约关联信息（比如appointment_id作为主键，用doc_id和pat_id作为外键关联医生和患者表，再加上appointment_date, appointment_time, status等字段）
  如果需要管理医生的固定排班，还可以额外加一张Doctor_Schedules表，专门存储医生的可预约时段，这样查询可用时间的逻辑会清晰很多。

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