MySQL表结构应映射业务语义而非类图语法，用外键表达关联、单表继承+CHECK约束处理多态、TINYINT+注释替代字符串枚举，谨慎冗余低频变更字段以平衡性能与一致性。
MySQL 表结构不能直接套用类图，但可以映射核心关系
MySQL 是关系型数据库，没有继承、封装、多态这些面向对象概念。所谓“符合面向对象”，其实是把业务领域模型中的实体、关联、约束，用表、外键、索引、CHECK（8.0.16+）等机制合理表达出来。关键不是模仿语法，而是对齐语义。
-
用户类 →users表，字段对应属性，id主键即对象标识 - “一个订单属于一个用户” →
orders.user_id外键引用users.id，而非在orders表里存user对象实例 - “订单有多个商品项” → 拆成
order_items关联表，体现一对多，不是把 JSON 数组塞进orders.items
枚举和状态字段别用字符串硬编码，优先用 TINYINT + 注释或字典表
比如 order.status 字段，如果定义为 VARCHAR(20) 存 'pending'、'shipped'，会导致拼写错误、大小写不一致、查询慢、无法用数字索引加速。这不是“面向对象不好”，是关系模型下典型的反模式。
- 推荐：用
TINYINT UNSIGNED，值 0/1/2/3，配合列注释说明含义，例如COMMENT '0: pending, 1: paid, 2: shipped, 3: completed' - 更严格场景（如需运行时可配置、多语言支持）：建
order_status字典表，orders.status_id外键引用，避免魔法数字散落各处 - 避免用
ENUM：增删值需 ALTER TABLE，线上变更风险高；且 ORM 映射容易出错，比如 Django 的choices和 DB 实际值不同步
继承关系不要建父子表，用单表继承或类型字段 + 可空列
面向对象中 Payment 有子类 CreditCardPayment 和 AlipayPayment，不代表你要建三张表 payments、credit_card_payments、alipay_payments 并用外键关联——这会极大增加 JOIN 成本，也违背第三范式（字段依赖于主键，而非部分主键）。
- 更实用做法：单表
payments，含通用字段（id,amount,created_at），再加type字段（TINYINT或VARCHAR(16)），以及所有子类可能用到的可空字段，如card_last4、alipay_trade_no - 用 CHECK 约束保证字段互斥（MySQL 8.0.16+）：
CHECK ((type = 1 AND card_last4 IS NOT NULL AND alipay_trade_no IS NULL) OR (type = 2 AND alipay_trade_no IS NOT NULL AND card_last4 IS NULL))
- 如果子类字段差异极大、读写比例严重倾斜，才考虑垂直分表（如
payment_cards单独存卡信息），但必须由明确性能数据驱动，而非“看起来更像 OOP”
避免过度规范化导致 JOIN 泛滥，必要时冗余关键字段
例如 orders 表需要显示用户昵称，而 users 表可能频繁更新 nike_name。严格按范式，每次查订单都得 JOIN users；但若业务要求列表页响应快、且昵称变更不频繁，可在 orders 中冗余 user_nickname 字段。
- 冗余前提：该字段变更频率低（如用户改昵称每月不到 1 次）、一致性可接受（允许几秒延迟）、且能通过应用层或触发器/事件驱动同步
- 绝不冗余主键、时间戳、金额类核心事实字段——这些一旦不一致，会导致账务错误
- JOIN 不是原罪，但 5 张表以上 JOIN + 分页 + ORDER BY，在千万级数据下基本不可维护；先看执行计划（
EXPLAIN），再决定是否冗余
