什么是数据库反模式
反模式（Anti-pattern）是指看似合理、但实际上会带来长期问题的设计方案。与单纯的错误不同，反模式通常在短期内能够"工作"，但随着业务发展会逐渐暴露出性能差、维护难、扩展性弱等问题。了解反模式比仅仅知道最佳实践更有价值，因为它让您理解"为什么不该这样做"。
反模式1：EAV（实体-属性-值）滥用
EAV结构用一张通用表存储所有类型的数据，看似灵活，实则是噩梦：
-- 反模式：EAV结构
CREATE TABLE entity_attributes (
entity_id UUID NOT NULL,
entity_type VARCHAR(50) NOT NULL,
attr_name VARCHAR(100) NOT NULL,
attr_value TEXT, -- 所有值都是字符串！
PRIMARY KEY (entity_id, attr_name)
);
-- 查询用户邮箱的代价极高
SELECT attr_value AS email
FROM entity_attributes
WHERE entity_id = $1 AND attr_name = 'email';
-- 更糟糕：查询价格大于100的商品
SELECT DISTINCT entity_id FROM entity_attributes
WHERE attr_name = 'price'
AND attr_value::DECIMAL > 100; -- 类型转换，无法使用索引
-- 正确方式：明确的列定义
CREATE TABLE users (
id UUID PRIMARY KEY,
email VARCHAR(255) NOT NULL,
name VARCHAR(200) NOT NULL,
created_at TIMESTAMP NOT NULL
);
CREATE TABLE products (
id UUID PRIMARY KEY,
name VARCHAR(200) NOT NULL,
price DECIMAL(10,2) NOT NULL,
description TEXT,
created_at TIMESTAMP NOT NULL
);
何时EAV是合理的：真正动态的扩展属性场景（如电商平台的商品规格），可以结合JSONB字段（PostgreSQL）作为补充，而非替代核心结构化字段。
反模式2：多态关联（Polymorphic Association）
多态关联使一个外键列根据另一个类型列指向不同的表，破坏了引用完整性：
-- 反模式：多态外键
CREATE TABLE comments (
id UUID PRIMARY KEY,
content TEXT NOT NULL,
commentable_id UUID NOT NULL, -- 可能指向posts.id 或 videos.id
commentable_type VARCHAR(50) NOT NULL, -- 'Post' 或 'Video'
created_at TIMESTAMP NOT NULL
);
-- 无法创建外键约束！数据库层面无法保证引用完整性
-- 查询所有帖子的评论数需要过滤type字段，性能差
-- 方案1：独立的关联表（推荐）
CREATE TABLE post_comments (
id UUID PRIMARY KEY,
post_id UUID NOT NULL REFERENCES posts(id),
content TEXT NOT NULL,
created_at TIMESTAMP NOT NULL
);
CREATE TABLE video_comments (
id UUID PRIMARY KEY,
video_id UUID NOT NULL REFERENCES videos(id),
content TEXT NOT NULL,
created_at TIMESTAMP NOT NULL
);
-- 方案2：父表 + 子表继承
CREATE TABLE comments (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
content TEXT NOT NULL,
user_id UUID NOT NULL REFERENCES users(id),
created_at TIMESTAMP NOT NULL DEFAULT NOW()
);
CREATE TABLE post_comments (
comment_id UUID PRIMARY KEY REFERENCES comments(id) ON DELETE CASCADE,
post_id UUID NOT NULL REFERENCES posts(id)
);
CREATE TABLE video_comments (
comment_id UUID PRIMARY KEY REFERENCES comments(id) ON DELETE CASCADE,
video_id UUID NOT NULL REFERENCES videos(id)
);
反模式3：用字符串存储列表
将多个值塞进一个字符串列，违反第一范式：
-- 反模式：逗号分隔的标签
CREATE TABLE articles (
id UUID PRIMARY KEY,
tags VARCHAR(500) -- 'technology,ai,database'
);
-- 查询含有特定标签的文章非常低效
SELECT * FROM articles WHERE tags LIKE '%ai%';
-- LIKE查询无法使用普通索引，且会误匹配 'brain'（含'ai'）
-- 正确方式：独立的关联表
CREATE TABLE tags (
id UUID PRIMARY KEY,
name VARCHAR(100) UNIQUE NOT NULL
);
CREATE TABLE article_tags (
article_id UUID REFERENCES articles(id) ON DELETE CASCADE,
tag_id UUID REFERENCES tags(id),
PRIMARY KEY (article_id, tag_id)
);
CREATE INDEX idx_article_tags_tag ON article_tags (tag_id);
-- 查询含有'ai'标签的文章，高效利用索引
SELECT a.* FROM articles a
JOIN article_tags at ON a.id = at.article_id
JOIN tags t ON at.tag_id = t.id
WHERE t.name = 'ai';
例外：如果确实只需要存储和展示，不需要按标签查询过滤，PostgreSQL的TEXT[]数组类型配合GIN索引是合理的折中。
反模式4：过度依赖自增整数ID暴露业务信息
使用连续自增ID会泄露业务信息（用户数量、订单量）并引发安全问题：
-- 反模式
CREATE TABLE orders (
id SERIAL PRIMARY KEY -- 攻击者通过 id=1, id=2 枚举所有订单
);
-- 推荐：UUID v4（随机，不可猜测）
CREATE TABLE orders (
id UUID PRIMARY KEY DEFAULT gen_random_uuid()
);
-- 或UUID v7（时序UUID，兼顾随机性和索引性能）
-- PostgreSQL 17+原生支持：DEFAULT gen_random_uuid() -- v4
-- 第三方扩展 pg_uuidv7：DEFAULT uuid_generate_v7()
反模式5：忽略NULL语义
NULL在SQL中有特殊语义，不等同于空字符串或0，忽视这一点会导致各种诡异的查询结果：
-- 这两个条件是不同的！
SELECT * FROM products WHERE price != 100; -- 不包含price为NULL的行
SELECT * FROM products WHERE price != 100 -- 包含price为NULL的行
OR price IS NULL;
-- 陷阱：NULL != NULL 结果为NULL（不是TRUE）
SELECT NULL = NULL; -- 结果：NULL
SELECT NULL IS NULL; -- 结果：TRUE
-- 明确设计NULL语义
CREATE TABLE subscriptions (
id UUID PRIMARY KEY,
user_id UUID NOT NULL,
expires_at TIMESTAMP, -- NULL表示永不过期（有意义的NULL）
cancelled_at TIMESTAMP -- NULL表示未取消（有意义的NULL）
);
使用Erdmates发现设计问题
Erdmates的ERD可视化帮助您在设计阶段直观发现潜在的反模式——缺少外键约束的关联关系、不合理的列类型、缺失的索引等都可以在图表中一目了然。在团队评审时，通过分享ERD链接让每个人都能发表意见，集体智慧往往能发现个人盲区。
好的数据库设计不是一次性完成的，而是随着对业务的深入理解不断演进的。定期审视现有Schema，及时识别和重构反模式，是维持数据库长期健康的关键。