MySQL数据库是否应使用CSL字符串？多对多关联方案咨询

嘿，针对你的问题先给个明确结论：绝对不要用逗号分隔字符串（CSL）来存储衬衫和颜色的关联——不管是存颜色ID还是颜色名称，这都是数据库设计里的典型反模式，会给你未来的维护、查询带来无穷麻烦。

为什么CSL是个坏主意？ #

• 查询效率极低：如果你想找所有红色的衬衫，用CSL的话得写WHERE colors LIKE '%1%'（假设红色ID是1），这种模糊匹配没法用索引，数据量稍微大一点就会卡成狗；而且还容易匹配到错误结果，比如ID是11的颜色也会被误捞出来。
• 无法保证数据完整性：你没法用外键约束来确保CSL里的ID/名称真的存在于colors表中，很容易出现脏数据（比如存了一个不存在的颜色ID）。
• 更新操作噩梦：如果某件衬衫要新增/删除一种颜色，你得先把整个字符串拆出来修改，再拼回去，不仅代码麻烦，还容易出现并发问题。
• 统计分析困难：想统计每种颜色对应的衬衫数量？用CSL的话得写复杂的字符串拆分逻辑，远不如关联查询简单直接。

正确的实现方式：用中间联结表（Junction Table） #

既然是多对多关系（一件衬衫对应多种颜色，一种颜色对应多件衬衫），标准做法是创建一个中间关联表，专门用来存储两者的对应关系。

举个具体的表结构例子：

1. shirts表（存储衬衫基础信息）：

CREATE TABLE shirts (
    shirt_id INT PRIMARY KEY AUTO_INCREMENT,
    shirt_name VARCHAR(100) NOT NULL,
    size VARCHAR(10),
    price DECIMAL(10,2),
    -- 其他衬衫相关字段
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

2. colors表（存储颜色信息）：

CREATE TABLE colors (
    color_id INT PRIMARY KEY AUTO_INCREMENT,
    color_name VARCHAR(50) NOT NULL UNIQUE,
    hex_code VARCHAR(7), -- 比如#FF0000
    -- 其他颜色相关字段
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

3. shirt_colors表（中间联结表，存储衬衫和颜色的关联）：

CREATE TABLE shirt_colors (
    shirt_id INT NOT NULL,
    color_id INT NOT NULL,
    PRIMARY KEY (shirt_id, color_id), -- 复合主键，避免重复关联
    FOREIGN KEY (shirt_id) REFERENCES shirts(shirt_id) ON DELETE CASCADE,
    FOREIGN KEY (color_id) REFERENCES colors(color_id) ON DELETE CASCADE
);

怎么用这个结构？ #

• 添加关联：比如ID为1的衬衫有红色（ID1）和蓝色（ID2）两种颜色，就插入两条记录：

INSERT INTO shirt_colors (shirt_id, color_id) VALUES (1, 1), (1, 2);

• 查询某件衬衫的所有颜色：

SELECT c.color_name, c.hex_code
FROM shirts s
JOIN shirt_colors sc ON s.shirt_id = sc.shirt_id
JOIN colors c ON sc.color_id = c.color_id
WHERE s.shirt_id = 1;

• 查询某颜色对应的所有衬衫：

SELECT s.shirt_name, s.size, s.price
FROM colors c
JOIN shirt_colors sc ON c.color_id = sc.color_id
JOIN shirts s ON sc.shirt_id = s.shirt_id
WHERE c.color_name = '红色';

补充：如果非要用CSL（强烈不推荐），存ID还是名称？ #

如果因为某些特殊原因你非要走这条路，优先存颜色ID而不是名称——因为颜色名称可能会修改（比如把“大红”改成“正红”），但ID是固定的，能减少数据不一致的风险。但还是那句话，这是饮鸩止渴，长远来看绝对是给自己挖坑。

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