多态关联中type字段应存类名（如"User"）或表名（如"users"）取决于框架与场景：主流框架默认存类名，纯SQL或跨语言建议存小写表名；foreign_key必须与type联合索引且type在前；禁用JSON替代外键；建模需显式标注多态并注明字段名。
多态关联里 type 字段该存类名还是表名？
存类名（如 "user"、"post"）是主流做法，尤其在 rails、laravel 等框架中默认如此；但如果你用的是纯 sql 或自研 orm，存表名（如 "users"、"posts"）反而更安全——它不依赖应用层的类命名约定，也不怕类名重构后数据失效。
常见错误：混用两者。比如后端写入 "User"，前端或迁移脚本却按 "users" 查询，结果查不到关联记录。
- PHP Laravel 默认用
model_type存类名（带命名空间），但可通过$morphClass覆盖 - Rails 的
commentable_type字段强制存类名，且对大小写敏感 - 如果跨语言服务共用这张表（比如 Go 写写入、Python 做分析），建议统一存小写表名，避免类名映射歧义
foreign_key 字段要不要加索引？
要，而且必须是联合索引，不是单列索引。
只给 foreign_key 加索引没用——数据库查多态关联时，永远同时过滤 foreign_key 和 type 两列。单列索引会导致全表扫描或回表，QPS 上去后延迟飙升。
典型错误现象：SELECT * FROM comments WHERE commentable_id = 123 AND commentable_type = 'Post' 执行慢，EXPLAIN 显示 type: ALL。
- 正确建索引：
CREATE INDEX idx_commentable ON comments (commentable_type, commentable_id) - 顺序不能反：
type必须在前，因为它是等值查询，而id通常是范围或等值，复合索引最左前缀才生效 - PostgreSQL 用户注意：
citext扩展可让type字段忽略大小写比较，避免因大小写不一致导致索引失效
用 JSON 字段替代多态外键行不行？
不行，除非你明确放弃 JOIN、约束和事务一致性。
有人想用 reference 字段存 {"type": "post", "id": 42} 来绕开多态设计，短期看着灵活，但立刻掉进三个坑：
- 无法外键约束：
ON DELETE CASCADE失效，删 Post 时不会自动删相关 comments - 无法 JOIN：
SELECT c.*, p.title FROM comments c JOIN posts p ON (c.reference->>'id')::int = p.id效率极低，且 PostgreSQL 对 JSON 字段的索引支持有限 - 类型不可控：
reference->>'id'可能是字符串、null、甚至恶意构造的 JSON，应用层校验成本陡增
真要动态关联，不如用单独的关联表（commentables），每种类型一行，用普通外键 + 类型字段，反而更可控。
可视化建模时怎么标清楚多态关系？
别用标准的“一对多”连线——UML 或 ER 图工具里，这种关系必须显式标注「多态」字样，并注明 type 和 foreign_key 字段名。
很多工具（如 dbdiagram.io、DBeaver 的 ER 图）不原生支持多态，强行画成普通外键会误导后续开发者以为这是固定表关联。
- 在字段备注里写死：
commentable_id → points to users.id OR posts.id depending on commentable_type - 导出 DDL 时，在注释里补一句：
-- POLYMORPHIC: commentable_type in ('User', 'Post') - 如果团队用 Mermaid，用
classDiagram而非erDiagram，手动加注释框说明行为边界
最常被忽略的一点：多态字段的 NOT NULL 和长度限制。比如 commentable_type VARCHAR(64) 看似够用，但 Laravel 5.8+ 默认存完整命名空间 "App\Models\Post"，超长就截断——一截断，关联直接失效，还查不出错在哪。
