技术选型：用户心愿单实现——关联表VS列存储序列化数据？

嘿，针对你提到的心愿单需求（支持用户把产品加到自定义分类里），我来拆解下两种方案的利弊，帮你选最适合的方向：

方案1：在users表新增序列化列（快速但局限） #

这种方式就是在users表里加个比如user_wish_list的列，用JSON、XML或者序列化字符串存数据，比如结构可能是这样的：

{"我的心仪服饰": [55, 67], "待购数码": [12, 34]}

优点 #

• 开发门槛极低，不用新建表，几行代码就能实现添加、读取功能，适合快速做Demo或者极小体量的项目。

缺点 #

这方案的问题真的挺多，生产环境慎用：

• 查询效率极低：比如你想统计「产品55被多少用户加入心愿单」，或者「给所有收藏了某类产品的用户发通知」，根本没法用SQL直接查询，得全表扫描每个用户的序列化数据再解析，数据量上来后性能直接崩。
• 数据一致性难维护：如果某个产品被删除或者ID变更，你得遍历所有用户的心愿单数据去更新，很容易出现遗漏，导致脏数据。
• 扩展性差：以后想加「心愿单排序」「添加时间记录」这类功能，只能往序列化结构里塞，不仅代码逻辑变复杂，还可能超出字段的存储上限。

方案2：规范化关联表设计（推荐生产环境使用） #

这是符合数据库设计范式的专业做法，需要新增两张关联表来实现：

1. 心愿单分类表（wishlist_categories） #

结构：

category_id INT PRIMARY KEY AUTO_INCREMENT,
user_id INT NOT NULL,
category_name VARCHAR(100) NOT NULL,
FOREIGN KEY (user_id) REFERENCES users(user_id) ON DELETE CASCADE

用来存储用户自定义的心愿单分类，比如用户「张三」的「我的心仪服饰」就是这张表里的一条记录。

2. 心愿单条目表（wishlist_items） #

结构：

item_id INT PRIMARY KEY AUTO_INCREMENT,
category_id INT NOT NULL,
product_id INT NOT NULL,
added_at DATETIME DEFAULT CURRENT_TIMESTAMP,
FOREIGN KEY (category_id) REFERENCES wishlist_categories(category_id) ON DELETE CASCADE,
FOREIGN KEY (product_id) REFERENCES products(product_id) ON DELETE CASCADE

用来关联分类和具体产品，比如把product_id=55加到「我的心仪服饰」分类，就是在这张表里插入一条对应category_id和product_id的记录。

优点 #

• 查询灵活高效：随便举个例子，想查产品55的收藏数，直接用SQL就能搞定：

SELECT COUNT(DISTINCT wc.user_id) 
FROM wishlist_items wi
JOIN wishlist_categories wc ON wi.category_id = wc.category_id
WHERE wi.product_id = 55;

• 数据一致性有保障：如果产品被删除，外键的ON DELETE CASCADE会自动删除对应的心愿单条目；用户修改分类名称，只需要更新wishlist_categories里的一条记录就行。
• 扩展性拉满：以后想加「心愿单排序权重」「是否公开」这类功能，直接给对应表加字段就行，完全不影响现有逻辑。
• 维护成本低：符合规范的结构，其他开发者接手也能快速理解，排查问题也更方便。

总结推荐 #

• 如果只是做个临时Demo，或者项目用户量极小、心愿单功能非常边缘，方案1可以凑合用；
• 只要是正式上线的项目，哪怕初期用户不多，也一定要选方案2——前期多花一点时间建表，后期能省无数维护和扩展的麻烦。

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